Apache Log4net's XmlLayout https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list and XmlLayoutSchemaLog4J https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list , in versions before 3.3.0, fail to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets in MDC property keys and values, as well as the identity field that may carry attacker-influenced data. This causes an exception during serialization and the silent loss of the affected log event.
An attacker who can influence any of these fields can exploit this to suppress individual log records, impairing audit trails and detection of malicious activity.
Users are advised to upgrade to Apache Log4net 3.3.0, which fixes this issue.
Apache Log4j's JsonTemplateLayout https://logging.apache.org/log4j/2.x/manual/json-template-layout.html , in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (NaN, Infinity, or -Infinity), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records.
An attacker can exploit this issue only if both of the following conditions are met:
* The application uses JsonTemplateLayout.
* The application logs a MapMessage, or logs an object directly (e.g., via Logger.info(Object), which wraps it in an ObjectMessage), where the message contains an attacker-controlled floating-point value.
Users are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue.
Note: The fix released in version 2.25.4 did not cover all affected code paths. CVE-2026-49844 was assigned to the remaining issue, which concerns the MapMessage.asJson() serialization in Apache Log4j API and is fixed in versions 2.25.5 and 2.26.1.
Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters.
The impact depends on the StAX implementation in use:
* JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.
* Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.
The Log4j1XmlLayout from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.
Two groups of users are affected:
* Those using Log4j1XmlLayout directly in a Log4j Core 2 configuration file.
* Those using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class.
Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4, which corrects this issue.
Note: The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the Log4j 1 to Log4j 2 migration guide https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html , and specifically the section on eliminating reliance on the bridge.
An improper encoding or escaping of output vulnerability exists in the JsonAccessLogValve component of Apache Tomcat. This affects multiple versions across Tomcat 9.0, 10.1, and 11.0 branches. The vulnerability allows for potential exposure of sensitive data due to improper handling of output encoding. Fixed versions have been released to address this issue.
ChurchCRM is an open-source church management system. Prior to 7.1.0, a stored cross-site scripting vulnerability exists in PersonView.php due to incorrect use of sanitizeText() as an output sanitizer for HTML attribute context. The function only strips HTML tags, it does not escape quote characters allowing an attacker to break out of the href attribute and inject arbitrary JavaScript event handlers. Any authenticated user with the EditRecords role can store the payload in a person's Facebook field. The XSS fires against any user who views that person's profile page, including administrators, enabling session hijacking and full account takeover. This vulnerability is fixed in 7.1.0.
CVE-2026-35208 is a cross-site scripting (XSS) vulnerability in the lichess-org lila platform. Approved streamers can inject arbitrary HTML into the /streamer page and the homepage Live streams widget by placing markup in their Twitch or YouTube stream title. Although a Content Security Policy (CSP) blocks inline script execution, the vulnerability still allows server-side HTML injection. To become an approved streamer, an account must be older than 2 days with at least 15 games or be verified/titled, and then receive moderator approval. The vulnerability affects versions prior to commit 0d5002696ae705e1888bf77de107c73de57bb1b3 and has a CVSS 4.0 score of 5.3 (medium severity).
GLPI versions from 11.0.0 up to but not including 11.0.6 contain a high-severity cross-site scripting (XSS) vulnerability. This flaw allows an unauthenticated user to store malicious scripts through the inventory endpoint. The vulnerability is addressed in version 11.0.6. The CVSS score is 7.
GLPI is a Free Asset and IT Management Software package. From 0.60 to before 10.0.24, an authenticated technician user can store an XSS payload in a supplier fields. This vulnerability is fixed in 10.0.24.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, the Handlebars CLI precompiler (`bin/handlebars` / `lib/precompiler.js`) concatenates user-controlled strings — template file names and several CLI options — directly into the JavaScript it emits, without any escaping or sanitization. An attacker who can influence template filenames or CLI arguments can inject arbitrary JavaScript that executes when the generated bundle is loaded in Node.js or a browser. Version 4.7.9 fixes the issue. Some workarounds are available. First, validate all CLI inputs before invoking the precompiler. Reject filenames and option values that contain characters with JavaScript string-escaping significance (`"`, `'`, `;`, etc.). Second, use a fixed, trusted namespace string passed via a configuration file rather than command-line arguments in automated pipelines. Third, run the precompiler in a sandboxed environment (container with no write access to sensitive paths) to limit the impact of successful exploitation. Fourth, audit template filenames in any repository or package that is consumed by an automated build pipeline.
Textpattern CMS version 4.9.0 contains a second-order cross-site scripting vulnerability that allows attackers to inject malicious scripts by exploiting improper sanitization of user-supplied input in Atom feed XML elements. Attackers can embed unescaped payloads in parameters such as category that are reflected into Atom fields like and , which execute as JavaScript when feed readers or CMS aggregators consume the feed and insert content into the DOM using unsafe methods.
Heimdall is a cloud native Identity Aware Proxy and Access Control Decision service. When using Heimdall in envoy gRPC decision API mode with versions 0.7.0-alpha through 0.17.10, wrong encoding of the query URL string allows rules with non-wildcard path expressions to be bypassed. Envoy splits the requested URL into parts, and sends the parts individually to Heimdall. Although query and path are present in the API, the query field is documented to be always empty and the URL query is included in the path field. The implementation uses go's url library to reconstruct the url which automatically encodes special characters in the path. As a consequence, a parameter like /mypath?foo=bar to Path is escaped into /mypath%3Ffoo=bar. Subsequently, a rule matching /mypath no longer matches and is bypassed. The issue can only lead to unintended access if Heimdall is configured with an "allow all" default rule. Since v0.16.0, Heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g.via --insecure-skip-secure-default-rule-enforcement or the broader --insecure flag. This issue has been fixed in version 0.17.11.
CVE-2026-32754 is a critical stored Cross-Site Scripting (XSS) vulnerability in FreeScout versions prior to 1.8.209. It arises from improper sanitization of incoming email bodies stored in the database and rendered unescaped in outgoing email notifications. An unauthenticated attacker can exploit this by sending a crafted email that, when viewed by any subscribed agent or admin, triggers universal HTML injection and potentially JavaScript execution in vulnerable email clients. This can lead to phishing, tracking, session hijacking, credential theft, and account takeover affecting all recipients simultaneously. The vulnerability is fixed in version 1.8.209. The CVSS score is 9.
jsPDF is a library to generate PDFs in JavaScript. Prior to version 4.2.1, user control of arguments of the `createAnnotation` method allows users to inject arbitrary PDF objects, such as JavaScript actions. If given the possibility to pass unsanitized input to the following method, a user can inject arbitrary PDF objects, such as JavaScript actions, which might trigger when the PDF is opened or interacted with the `createAnnotation`: `color` parameter. The vulnerability has been fixed in jsPDF@4.2.1. As a workaround, sanitize user input before passing it to the vulnerable API members.
LeafKit is a templating language with Swift-inspired syntax. Prior to version 1.14.2, HTML escaping doesn't work correctly when a template prints a collection (Array / Dictionary) via `#(value)`. This can result in XSS, allowing potentially untrusted input to be rendered unescaped. Version 1.14.2 fixes the issue.
The fix for CVE-2026-0672, which rejected control characters in http.cookies.Morsel, was incomplete. The Morsel.update(), |= operator, and unpickling paths were not patched, allowing control characters to bypass input validation. Additionally, BaseCookie.js_output() lacked the output validation applied to BaseCookie.output().
Craft is a content management system (CMS). The fix for CVE-2025-35939 in craftcms/cms introduced a strip_tags() call in src/web/User.php to sanitize return URLs before they are stored in the session. However, strip_tags() only removes HTML tags (angle brackets) -- it does not inspect or filter URL schemes. Payloads like javascript:alert(document.cookie) contain no HTML tags and pass through strip_tags() completely unmodified, enabling reflected XSS when the return URL is rendered in an href attribute. This vulnerability is fixed in 5.9.7 and 4.17.3.
### Summary
The `<base>` tag passes through the default `Cleaner` configuration. While `page_structure=True` removes `html`, `head`, and `title` tags, there is no specific handling for `<base>`, allowing an attacker to inject it and hijack relative links on the page.
### Details
The `<base>` tag is not currently in the `page_structure` kill set. Even though the specification says `<base>` must be inside `<head>`, browsers accept `<base>` tags outside of the head.
If an attacker injects a `<base>` tag, it changes the base URL for all relative URLs on the page (links, images, scripts) to a domain controlled by the attacker.
### PoC
```python
from lxml_html_clean import clean_html
# The base tag is preserved in the output
result = clean_html('<base href="http://evil.com/"><a href="/account">Account</a>')
print(result)
# Output: <div><base href="http://evil.com/">...<a href="/account">Account</a></div>
```
### Impact
The injection of a `<base>` tag allows an attacker to hijack the resolution of **all** relative URLs on the page. This results in three critical attack vectors:
1. **Phishing & Redirection:** Attackers can redirect user navigation (e.g., `<a href="/login">`) and form submissions (e.g., `<form action="/auth">`) to an attacker-controlled domain, effectively stealing credentials or sensitive data without the user realizing they have left the legitimate site.
2. **Cross-Site Scripting (XSS):** If the victim application loads JavaScript files using relative paths (e.g., `<script src="assets/app.js">`), the browser will attempt to fetch the script from the attacker's domain. This upgrades the vulnerability from HTML injection to full Stored XSS.
3. **Defacement:** Relative references to images (`<img>`) and stylesheets (`<link>`) will be loaded from the attacker's server, allowing for UI redressing or defacement.
lxml_html_clean is a project for HTML cleaning functionalities copied from `lxml.html.clean`. Prior to version 0.4.4, the _has_sneaky_javascript() method strips backslashes before checking for dangerous CSS keywords. This causes CSS Unicode escape sequences to bypass the @import and expression() filters, allowing external CSS loading or XSS in older browsers. This issue has been patched in version 0.4.4.
Sub2API is an AI API gateway platform designed to distribute and manage API quotas from AI product subscriptions. A vulnerability in versions prior to 0.1.85 is a Password Reset Poisoning (Host Header / Forwarded Header trust issue), which allows attackers to manipulate the password reset link. Attackers can exploit this flaw to inject their own domain into the password reset link, leading to the potential for account takeover. The vulnerability has been fixed in version v0.1.85. If upgrading is not immediately possible, users can mitigate the vulnerability by disabling the "forgot password" feature until an upgrade to a patched version can be performed. This will prevent attackers from exploiting the vulnerability via the affected endpoint.