Where
-Infinity
0

Vendor Risk Score

See how thephpleague compares to other vendors in security performance

View Risk Score →
Severity
8.2
Infoleak
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Impact Servers that passed their keys to the CryptKey constructor as as string instead of a file path will have had that key included in a LogicException message if they did not provide a valid pass phrase for the key where required.

Patches This issue has been patched so that the provided key is no longer exposed in the exception message in the scenario outlined above. Users should upgrade to version 8.5.3 or 8.4.2 to receive the patch.

Workarounds We recommend upgrading the oauth2-server to one of the patched releases (8.5.3 or 8.4.2). If you are unable to upgrade you can avoid this security issue by passing your key as a file instead of a string.

References Fix for 8.4.x Fix for 8.5.x

1 / 2
First published (updated )
Severity
6.3
EPSS
0.04%
XSS, SSRF
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

The DomainFilteringAdapter in the Embed extension is vulnerable to an allowlist bypass due to a missing hostname boundary assertion in the domain-matching regex. An attacker-controlled domain like youtube.com.evil passes the allowlist check when youtube.com is an allowed domain.

This enables two attack vectors:

- SSRF: The OscaroteroEmbedAdapter makes server-side HTTP requests to the embed URL via the embed/embed library. A bypassed domain filter causes the server to make outbound requests to an attacker-controlled host, potentially probing internal services or exfiltrating request metadata. - XSS: EmbedRenderer outputs the oEmbed response HTML directly into the page with no sanitization. An attacker controlling the bypassed domain can return arbitrary HTML/JavaScript in their oEmbed response, which is rendered verbatim.

Any application using the Embed extension and relying on alloweddomains to restrict domains when processing untrusted Markdown input is affected.

Patches

This has been patched in version 2.8.2. The fix replaces the regex-based domain check with explicit hostname parsing using parseurl(), ensuring exact domain and subdomain matching only.

Workarounds

- Disable the Embed extension, or restrict its use to trusted users - Provide your own domain-filtering implementation of EmbedAdapterInterface - Enable a Content Security Policy (CSP) and outbound firewall restrictions

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
EPSS
0.03%
XSS
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

The DisallowedRawHtml extension can be bypassed by inserting a newline, tab, or other ASCII whitespace character between a disallowed HTML tag name and the closing >. For example, <script\n> would pass through unfiltered and be rendered as a valid HTML tag by browsers. This is a cross-site scripting (XSS) vector for any application that relies on this extension to sanitize untrusted user input.

All applications using the DisallowedRawHtml extension to process untrusted markdown are affected. Applications that use a dedicated HTML sanitizer (such as HTML Purifier) on the rendered output are not affected.

Patches

Fixed in 2.8.1. The regex character class [ \/>] was changed to [\s\/>] to match all whitespace characters that browsers accept as valid tag name terminators.

Workarounds

- Set the htmlinput configuration option to 'escape' or 'strip' to disable all raw HTML, though this is a broader restriction than the DisallowedRawHtml extension provides. - Pass the rendered HTML through a dedicated HTML sanitizer before serving it to users (always recommended)

Resources

- CommonMark DisallowedRawHtml documentation - CWE-79: Improper Neutralization of Input During Web Page Generation - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
XSS
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Cross-site scripting (XSS) vulnerability in the PHP League CommonMark library versions 0.15.6 through 0.18.x before 0.18.1 allows remote attackers to insert unsafe URLs into HTML (even if allowunsafelinks is false) via a newline character (e.g., writing javascript as javascri%0apt).

1 / 2
First published (updated )
Severity
6.1
XSS
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

CVE-2019-10010

Impact

In league/commonmark 0.18.2 and below, malicious users can insert double-encoded HTML entities into their Markdown like this:

md XSS

This library would (correctly) unescape the &amp; entity to & during the parsing step. However, the renderer step would fail to properly re-escape the resulting &colon; string, thus producing the following malicious HTML output:

html <p><a href="javascript&colon;alert('XSS')">XSS</a></p>

Browsers would interpret &colon; as a : character and allow the JS to be executed when the link is clicked.

This vulnerability was present in the upstream library this project was forked from and therefore exists in all prior versions of league/commonmark.

Solution

The new 0.18.3 release mirrors the fix made upstream - we no longer attempt to preserve entities when rendering HTML attributes like href, src, title, etc.

The $preserveEntities parameter of Xml::escape() is therefore no longer used internally, so it has been deprecated and marked for removal in the next major release (0.19.0).

Credits

- Mohit Fawaz for identifying the issue - Sebastiaan Knijnenburg and Ross Tuck for responsibly disclosing/relaying the issue - John MacFarlane for investigating it and implementing the upstream fix we mirrored here

References

- https://nvd.nist.gov/vuln/detail/CVE-2019-10010 - https://github.com/thephpleague/commonmark/releases/tag/0.18.3 - https://github.com/thephpleague/commonmark/issues/353 - https://github.com/FriendsOfPHP/security-advisories/blob/master/league/commonmark/CVE-2019-10010.yaml

1 / 3
Source: GitHub
First published (updated )
Severity
9.8
Race Condition
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Impact

The whitespace normalisation using in 1.x and 2.x removes any unicode whitespace. Under certain specific conditions this could potentially allow a malicious user to execute code remotely.

The conditions:

- A user is allowed to supply the path or filename of an uploaded file. - The supplied path or filename is not checked against unicode chars. - The supplied pathname checked against an extension deny-list, not an allow-list. - The supplied path or filename contains a unicode whitespace char in the extension. - The uploaded file is stored in a directory that allows PHP code to be executed.

Given these conditions are met a user can upload and execute arbitrary code on the system under attack.

Patches

The unicode whitespace removal has been replaced with a rejection (exception).

The library has been patched in: - 1.x: https://github.com/thephpleague/flysystem/commit/f3ad69181b8afed2c9edf7be5a2918144ff4ea32 - 2.x: https://github.com/thephpleague/flysystem/commit/a3c694de9f7e844b76f9d1b61296ebf6e8d89d74

Workarounds

For 1.x users, upgrade to 1.1.4. For 2.x users, upgrade to 2.1.1.

1 / 3
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203