🚨 CVE-2026-75918
phpMyFAQ before 4.1.7 stores password reset tokens in a publicly accessible tracking file when user tracking is enabled. Unauthenticated attackers can read the tracking file at content/core/data/trackingDDMMYYYY to extract reset tokens and replay them against the password reset API to take over user accounts.
🎖@cveNotify
phpMyFAQ before 4.1.7 stores password reset tokens in a publicly accessible tracking file when user tracking is enabled. Unauthenticated attackers can read the tracking file at content/core/data/trackingDDMMYYYY to extract reset tokens and replay them against the password reset API to take over user accounts.
🎖@cveNotify
GitHub
Public Tracking File Leaks Password Reset Tokens to Unauthenticated Users
Hi Thorsten,
I'm reporting an account-takeover issue in phpMyFAQ's user tracking feature. A public tracking file records the full query string for every visited frontend page. Password r...
I'm reporting an account-takeover issue in phpMyFAQ's user tracking feature. A public tracking file records the full query string for every visited frontend page. Password r...
🚨 CVE-2026-75919
phpMyFAQ before 4.1.7 contains an authentication bypass vulnerability in SetupController that allows unauthenticated attackers to run database migrations and create configuration backups when maintenance mode is enabled. Attackers can call POST /api/setup/update-database and POST /api/setup/backup endpoints to execute database updates, disable maintenance mode, and extract database credentials from generated ZIP archives.
🎖@cveNotify
phpMyFAQ before 4.1.7 contains an authentication bypass vulnerability in SetupController that allows unauthenticated attackers to run database migrations and create configuration backups when maintenance mode is enabled. Attackers can call POST /api/setup/update-database and POST /api/setup/backup endpoints to execute database updates, disable maintenance mode, and extract database credentials from generated ZIP archives.
🎖@cveNotify
GitHub
Unauthenticated Backup + DB Migration and Maintenance Mode Bypass
# Unauthenticated Setup API: Database Migration and Maintenance Bypass
Hi,
I’m reporting an issue in the setup/update REST endpoints. While the site is in maintenance mode, unauthenticated ca...
Hi,
I’m reporting an issue in the setup/update REST endpoints. While the site is in maintenance mode, unauthenticated ca...
🚨 CVE-2026-75920
phpMyFAQ before v4.1.6 writes content backup ZIP archives to the web-accessible document root at content.zip, exposing sensitive files including database credentials. Unauthenticated attackers can race concurrent requests to download the temporary ZIP file before deletion, or exploit XSS in admin contexts to trigger authenticated backups and retrieve the archive.
🎖@cveNotify
phpMyFAQ before v4.1.6 writes content backup ZIP archives to the web-accessible document root at content.zip, exposing sensitive files including database credentials. Unauthenticated attackers can race concurrent requests to download the temporary ZIP file before deletion, or exploit XSS in admin contexts to trigger authenticated backups and retrieve the archive.
🎖@cveNotify
GitHub
Sensitive Content Backup ZIP Written to Web-Accessible Document Root
Hi Thorsten,
I’m reporting a information disclosure issue in the content backup API. Creating a content backup writes a ZIP archive to `{PMF_ROOT}/content.zip`, which is directly reachable over ...
I’m reporting a information disclosure issue in the content backup API. Creating a content backup writes a ZIP archive to `{PMF_ROOT}/content.zip`, which is directly reachable over ...
🚨 CVE-2026-76205
phpMyFAQ before 4.1.7 contains a SQL injection vulnerability in the glossary create and update endpoints caused by truncating an escaped string before embedding it in a SQL literal. Authenticated users with glossary add or edit permissions can craft a payload with a dangling backslash to escape the closing quote and inject arbitrary SQL commands to read sensitive database information.
🎖@cveNotify
phpMyFAQ before 4.1.7 contains a SQL injection vulnerability in the glossary create and update endpoints caused by truncating an escaped string before embedding it in a SQL literal. Authenticated users with glossary add or edit permissions can craft a payload with a dangling backslash to escape the closing quote and inject arbitrary SQL commands to read sensitive database information.
🎖@cveNotify
GitHub
SQL Injection via Glossary Escape-Then-Truncate
Hi Thorsten,
I’m reporting a classic SQL injection in phpMyFAQ’s glossary create/update persistence path. The application escapes the glossary item, then truncates the *escaped* string with `sub...
I’m reporting a classic SQL injection in phpMyFAQ’s glossary create/update persistence path. The application escapes the glossary item, then truncates the *escaped* string with `sub...
🚨 CVE-2026-76206
phpMyFAQ versions before 4.1.7 fail to validate active status in the PDF export endpoint, allowing unauthenticated attackers to retrieve draft FAQ metadata. Attackers can access the public PDF export route with sequential FAQ identifiers to obtain titles, solution IDs, author names, and last-update timestamps of inactive or unpublished FAQs.
🎖@cveNotify
phpMyFAQ versions before 4.1.7 fail to validate active status in the PDF export endpoint, allowing unauthenticated attackers to retrieve draft FAQ metadata. Attackers can access the public PDF export route with sequential FAQ identifiers to obtain titles, solution IDs, author names, and last-update timestamps of inactive or unpublished FAQs.
🎖@cveNotify
GitHub
Public PDF export has no active-status gate, so an unauthenticated visitor can retrieve the title, solution id
### Summary
Public PDF export has no active-status gate, so an unauthenticated visitor can retrieve the title, solution id
The public PDF export never checks whether the FAQ is active, so an unau...
Public PDF export has no active-status gate, so an unauthenticated visitor can retrieve the title, solution id
The public PDF export never checks whether the FAQ is active, so an unau...
🚨 CVE-2026-76207
phpMyFAQ before 4.1.7 contains a two-factor authentication bypass vulnerability where remember-me tokens are issued before 2FA verification completes. Attackers with valid credentials can obtain a remember-me cookie, skip the 2FA challenge, and replay the cookie to gain full authenticated access without second-factor verification.
🎖@cveNotify
phpMyFAQ before 4.1.7 contains a two-factor authentication bypass vulnerability where remember-me tokens are issued before 2FA verification completes. Attackers with valid credentials can obtain a remember-me cookie, skip the 2FA challenge, and replay the cookie to gain full authenticated access without second-factor verification.
🎖@cveNotify
GitHub
006 2FA Bypass via Remember-Me Cookie Issued Before Second Factor Verification
### Summary
A logic flaw in the authentication flow allows an attacker with valid credentials to bypass two-factor authentication (2FA) entirely. When a user logs in with "Remember me"...
A logic flaw in the authentication flow allows an attacker with valid credentials to bypass two-factor authentication (2FA) entirely. When a user logs in with "Remember me"...
🚨 CVE-2026-76208
phpMyFAQ versions 3.1.0 through 4.1.6 contain an authentication bypass vulnerability in AuthLdap::create(). When LDAP authentication is enabled, after a successful LDAP bind the code calls User::setStatus('active') unconditionally, which overwrites the account_status column of a pre-existing local account from 'blocked' to 'active'. As a result, a user whose local phpMyFAQ account has been administratively blocked can restore their account and log in by authenticating via LDAP. The state transition is not logged, so administrators cannot detect that the block was overridden. Fixed in 4.1.7.
🎖@cveNotify
phpMyFAQ versions 3.1.0 through 4.1.6 contain an authentication bypass vulnerability in AuthLdap::create(). When LDAP authentication is enabled, after a successful LDAP bind the code calls User::setStatus('active') unconditionally, which overwrites the account_status column of a pre-existing local account from 'blocked' to 'active'. As a result, a user whose local phpMyFAQ account has been administratively blocked can restore their account and log in by authenticating via LDAP. The state transition is not logged, so administrators cannot detect that the block was overridden. Fixed in 4.1.7.
🎖@cveNotify
GitHub
029 LDAP login silently reactivates blocked local accounts without logging the state change
### Summary
When LDAP authentication is enabled, `AuthLdap::create()` calls `User::setStatus('active')` unconditionally after a successful LDAP bind — even when the local phpMyFAQ accoun...
When LDAP authentication is enabled, `AuthLdap::create()` calls `User::setStatus('active')` unconditionally after a successful LDAP bind — even when the local phpMyFAQ accoun...
🚨 CVE-2026-76209
phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page.
🎖@cveNotify
phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page.
🎖@cveNotify
GitHub
Registration Bypass When security.enableRegistration Is Disabled
# Registration Bypass When `security.enableRegistration` Is Disabled
Hi,
I’m reporting an authorization issue that allows new user accounts to be created even when public registration is disa...
Hi,
I’m reporting an authorization issue that allows new user accounts to be created even when public registration is disa...
🚨 CVE-2026-76210
phpMyFAQ before 4.1.7 does not adequately sanitize HTML in FAQ answers before generating PDFs via TCPDF. An attacker with permission to create or edit FAQ content can embed an <img> tag whose src references a local file under the web root's content/ directory (e.g., content/core/config/database.php). When the PDF is generated, phpMyFAQ attempts to read the referenced file; because it is not a valid image the resulting error is converted into an uncaught exception whose stack trace discloses part of the file's contents to any user who triggers the PDF export. By default the disclosed portion is truncated (zend.exception_string_param_max_len), but a larger configured value can result in disclosure of entire files, including database credentials.
🎖@cveNotify
phpMyFAQ before 4.1.7 does not adequately sanitize HTML in FAQ answers before generating PDFs via TCPDF. An attacker with permission to create or edit FAQ content can embed an <img> tag whose src references a local file under the web root's content/ directory (e.g., content/core/config/database.php). When the PDF is generated, phpMyFAQ attempts to read the referenced file; because it is not a valid image the resulting error is converted into an uncaught exception whose stack trace discloses part of the file's contents to any user who triggers the PDF export. By default the disclosed portion is truncated (zend.exception_string_param_max_len), but a larger configured value can result in disclosure of entire files, including database credentials.
🎖@cveNotify
GitHub
Arbitrary Local File Disclosure via PDF Export HTML Image Handling
Hi Thorsten,
It has been a long time :3 ... I’m reporting a high-impact issue in phpMyFAQ’s PDF export functionality that can disclose sensitive files from the server's `content/` directory,...
It has been a long time :3 ... I’m reporting a high-impact issue in phpMyFAQ’s PDF export functionality that can disclose sensitive files from the server's `content/` directory,...
🚨 CVE-2026-76211
phpMyFAQ before 4.1.7 fails to properly enforce CONFIGURATION_EDIT permission on admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration, allowing any authenticated user to access sensitive administrative data. Attackers can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics by calling these endpoints with a valid session.
🎖@cveNotify
phpMyFAQ before 4.1.7 fails to properly enforce CONFIGURATION_EDIT permission on admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration, allowing any authenticated user to access sensitive administrative data. Attackers can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics by calling these endpoints with a valid session.
🎖@cveNotify
GitHub
Admin config-read API endpoints (LDAP, Elasticsearch, OpenSearch, dashboard) are gated by login only, not CONFIGURATION_EDIT
### Summary
Admin config-read API endpoints (LDAP, Elasticsearch, OpenSearch, dashboard) are gated by login only, not CONFIGURATION_EDIT
## Affected versions and vulnerable location
- Conf...
Admin config-read API endpoints (LDAP, Elasticsearch, OpenSearch, dashboard) are gated by login only, not CONFIGURATION_EDIT
## Affected versions and vulnerable location
- Conf...
🚨 CVE-2026-76213
phpMyFAQ before 4.1.7 contains a brute-force vulnerability in the two-factor authentication step where the failure counter is session-scoped and reset on each successful password re-authentication. Attackers with a valid password can bypass the five-attempt limit by obtaining a fresh session cookie and repeatedly re-authenticating to reset the counter, enabling unbounded TOTP code guessing.
🎖@cveNotify
phpMyFAQ before 4.1.7 contains a brute-force vulnerability in the two-factor authentication step where the failure counter is session-scoped and reset on each successful password re-authentication. Attackers with a valid password can bypass the five-attempt limit by obtaining a fresh session cookie and repeatedly re-authenticating to reset the counter, enabling unbounded TOTP code guessing.
🎖@cveNotify
GitHub
Admin 2FA brute-force throttle is session-scoped, so a fresh cookie jar resets the counter and TOTP codes can be guessed at will
### Summary
Admin 2FA brute-force throttle is session-scoped, so a fresh cookie jar resets the counter and TOTP codes can be guessed at will
## Affected versions and vulnerable location
- ...
Admin 2FA brute-force throttle is session-scoped, so a fresh cookie jar resets the counter and TOTP codes can be guessed at will
## Affected versions and vulnerable location
- ...
🚨 CVE-2026-76214
phpMyFAQ before 4.1.7 (affected versions <= 4.1.5) fails to persist the WebAuthn login challenge generated by prepareForLogin, because neither WebAuthn controller saves the mutated key objects back to the database. At login the anti-replay comparison is skipped by its own null guard, allowing an attacker who captures a successful WebAuthn assertion to replay it indefinitely and authenticate as the user without any interaction or hardware key.
🎖@cveNotify
phpMyFAQ before 4.1.7 (affected versions <= 4.1.5) fails to persist the WebAuthn login challenge generated by prepareForLogin, because neither WebAuthn controller saves the mutated key objects back to the database. At login the anti-replay comparison is skipped by its own null guard, allowing an attacker who captures a successful WebAuthn assertion to replay it indefinitely and authenticate as the user without any interaction or hardware key.
🎖@cveNotify
GitHub
WebAuthn login challenge is never persisted, so the replay guard is skipped and captured assertions can be replayed
## Summary
`prepareForLogin` generates a per-login challenge and writes it onto the stored key objects, but neither WebAuthn controller saves the result. At login the keys are re-read from the d...
`prepareForLogin` generates a per-login challenge and writes it onto the stored key objects, but neither WebAuthn controller saves the result. At login the keys are re-read from the d...
🚨 CVE-2026-76215
phpMyFAQ before 4.1.7 fails to apply parent FAQ visibility checks before returning child resources including comments and attachments. Unauthenticated attackers can retrieve restricted comment text, commenter email addresses, and attachment filenames for FAQ records they cannot directly access by querying the comments and attachments API endpoints.
🎖@cveNotify
phpMyFAQ before 4.1.7 fails to apply parent FAQ visibility checks before returning child resources including comments and attachments. Unauthenticated attackers can retrieve restricted comment text, commenter email addresses, and attachment filenames for FAQ records they cannot directly access by querying the comments and attachments API endpoints.
🎖@cveNotify
GitHub
Missing parent FAQ authorization exposes comments, commenter PII, and attachment metadata of restricted records
## Summary
phpMyFAQ 4.1.6 does not consistently apply parent FAQ visibility checks before returning child resources for a FAQ record.
In a local installed 4.1.6 release, an authenticated admi...
phpMyFAQ 4.1.6 does not consistently apply parent FAQ visibility checks before returning child resources for a FAQ record.
In a local installed 4.1.6 release, an authenticated admi...
🚨 CVE-2026-76216
Vikunja through 2.4.0 contains a principal-type confusion vulnerability where LinkSharing principals with id N are treated as user principals with users.id == N at three permission checks lacking type guards. Attackers with a link-share JWT can remove victims from teams, enumerate and delete victim bot users, or read team rosters by exploiting id collisions in the autoincrement space.
🎖@cveNotify
Vikunja through 2.4.0 contains a principal-type confusion vulnerability where LinkSharing principals with id N are treated as user principals with users.id == N at three permission checks lacking type guards. Attackers with a link-share JWT can remove victims from teams, enumerate and delete victim bot users, or read team rosters by exploiting id collisions in the autoincrement space.
🎖@cveNotify
GitHub
Link-share principal-type confusion enables cross-account team removal, bot takeover, and roster disclosure
## Summary
Vikunja's `web.Auth` interface (`pkg/web/web.go`, single method `GetID() int64`) is satisfied by BOTH `*user.User` and `*models.LinkSharing`. A link-share's `GetID()` returns the...
Vikunja's `web.Auth` interface (`pkg/web/web.go`, single method `GetID() int64`) is satisfied by BOTH `*user.User` and `*models.LinkSharing`. A link-share's `GetID()` returns the...
🚨 CVE-2026-76217
GitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.
🎖@cveNotify
GitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.
🎖@cveNotify
GitHub
Arbitrary file read via --pathspec-from-file in IndexFile.remove() and Head.checkout()
## Summary
`IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout`
with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-...
`IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout`
with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-...
🚨 CVE-2026-76218
GitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.
🎖@cveNotify
GitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.
🎖@cveNotify
GitHub
Unguarded git option forwarding in Repo.init enables arbitrary command execution via --template clone hooks
## Summary
`Repo.init()` forwards `**kwargs` verbatim to `git init` with no unsafe-option guard and no `allow_unsafe_options` parameter. `git init --template=<dir>` copies `<dir>/hooks...
`Repo.init()` forwards `**kwargs` verbatim to `git init` with no unsafe-option guard and no `allow_unsafe_options` parameter. `git init --template=<dir>` copies `<dir>/hooks...
🚨 CVE-2026-76219
GitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.
🎖@cveNotify
GitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.
🎖@cveNotify
GitHub
Unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree enables arbitrary file overwrite
## Summary
`IndexFile.from_tree`, `IndexFile.reset` (→ from_tree) and `IndexFile.merge_tree` append caller-influenced treeish strings positionally to `git read-tree` with no unsafe-option guard, n...
`IndexFile.from_tree`, `IndexFile.reset` (→ from_tree) and `IndexFile.merge_tree` append caller-influenced treeish strings positionally to `git read-tree` with no unsafe-option guard, n...
🚨 CVE-2026-76220
GitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.
🎖@cveNotify
GitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.
🎖@cveNotify
GitHub
Unsafe git option guard bypass via split_single_char_options=False short-option token smuggling enables command execution
## Summary
The `check_unsafe_options` guard can be bypassed on every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by combining a single-character kwa...
The `check_unsafe_options` guard can be bypassed on every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by combining a single-character kwa...
🚨 CVE-2026-76221
GitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like 'sshCommand = touch /tmp/RCE #' to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.
🎖@cveNotify
GitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like 'sshCommand = touch /tmp/RCE #' to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.
🎖@cveNotify
GitHub
git-config OPTION-name injection via =/#/whitespace bypasses name validator, enabling forged core.sshCommand/hooksPath (RCE)
## Summary
GitPython's config-name validator only neutralizes CR/LF/NUL for the `"option"` label; it does not reject `=`, `#`, `;`, `[`, `]`, or whitespace in an **option name**. `wr...
GitPython's config-name validator only neutralizes CR/LF/NUL for the `"option"` label; it does not reject `=`, `#`, `;`, `[`, `]`, or whitespace in an **option name**. `wr...
🚨 CVE-2026-76222
GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.
🎖@cveNotify
GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.
🎖@cveNotify
GitHub
Arbitrary Git Repository Creation Outside the Working Tree via Unvalidated .gitmodules Submodule Name in GitPython
### Summary
GitPython computes the on-disk location of a submodule's separate Git directory (`.git/modules/<name>`) from the submodule's `.gitmodules` section name with no validation...
GitPython computes the on-disk location of a submodule's separate Git directory (`.git/modules/<name>`) from the submodule's `.gitmodules` section name with no validation...
🚨 CVE-2026-76223
ArcadeDB (com.arcadedb) versions 26.7.3 and earlier fail to enforce the UPDATE_SCHEMA permission check when a DEFINE FUNCTION statement targets an already-existing function library. A user with only database access can add or overwrite SQL or Cypher functions in an existing library and persist the change, enabling tampering with admin-defined function logic. The issue is fixed in 26.8.1. (JavaScript functions still trigger the UPDATE_SECURITY check and are not affected.)
🎖@cveNotify
ArcadeDB (com.arcadedb) versions 26.7.3 and earlier fail to enforce the UPDATE_SCHEMA permission check when a DEFINE FUNCTION statement targets an already-existing function library. A user with only database access can add or overwrite SQL or Cypher functions in an existing library and persist the change, enabling tampering with admin-defined function logic. The issue is fixed in 26.8.1. (JavaScript functions still trigger the UPDATE_SECURITY check and are not affected.)
🎖@cveNotify
GitHub
DEFINE FUNCTION into an existing library skips UPDATE_SCHEMA permission check
## Summary
`DEFINE FUNCTION` into an already-existing function library skips the UPDATE_SCHEMA permission check. A user with only DB access can add or overwrite sql/cypher functions in an existing...
`DEFINE FUNCTION` into an already-existing function library skips the UPDATE_SCHEMA permission check. A user with only DB access can add or overwrite sql/cypher functions in an existing...