Vulnerabilities

MISP versions 2.5.45 and earlier accept attacker-controlled email input on the unauthenticated forgot-password reset endpoint without a length bound or format validation, persisting the supplied value twice per request (once in an audit log entry and once in a queued password-reset job) with no rate limiting. An unauthenticated attacker can repeatedly submit oversized or arbitrary values to this and similar pre-auth paths (registrations, failed REST authentication attempts), driving unbounded growth of persistent storage and queued work. The result is high availability impact (CVSS 4.0 8.7, VA:High): resource exhaustion can degrade or disrupt the instance, while confidentiality and integrity are unaffected. Any MISP deployment running 2.5.45 or earlier is affected, particularly instances where the pre-auth reset flow is reachable by untrusted users. No public PoC, no CISA KEV listing, and an EPSS of about 0.3% indicate no known exploitation at this time.

Do: Upgrade MISP to a release newer than 2.5.45, which adds the 1024-byte email length cap, email-format validation before persistent work, a per-source pre-auth request budget with HTTP 429 responses, and a 15-minute cooldown for API-access request emails. Until patched, rate-limit or restrict unauthenticated access to the forgot-password and other pre-auth endpoints at a reverse proxy or WAF, and monitor audit-log and job-queue growth for signs of storage exhaustion. Also verify the API-access request endpoint is POST-only with CSRF protection in the deployed version.

MISP's custom LdapAuthenticate and LinOTPAuthenticate components, which replace CakePHP's FormAuthenticate, failed to replicate its credential validation, allowing empty or non-string values to reach the underlying authentication mechanisms. A remote attacker who knows a valid directory user's email address can submit an empty password, which is passed to ldap_bind(); if the LDAP server accepts unauthenticated binds, the bind succeeds and MISP treats the attacker as that directory user without verifying any password. The flaw also affects the LinOTP path and local fallback: with mixed authentication enabled, an empty password can be checked against a stored MISP password hash, and LDAP-provisioned accounts may have been created with an empty local password that remains usable once the account is no longer resolved through LDAP. Successful exploitation lets an unauthenticated attacker impersonate an existing MISP user — potentially an administrator — gaining access to sensitive threat-intelligence data and the ability to modify or delete it and alter configuration. Only MISP deployments with the LDAP or LinOTP authentication components enabled are affected; no public proof-of-concept or in-the-wild exploitation is known (EPSS 0.5%, not in CISA KEV).

Do: Upgrade MISP to the patched release addressing CVE-2026-85216; the fix enforces valid string credentials, rejects empty passwords where not permitted, and assigns randomly generated local passwords to LDAP-provisioned accounts. As interim mitigations, configure the LDAP directory to reject unauthenticated (empty-password) binds, disable mixed authentication with LinOTP if not needed, and reset the local passwords of LDAP-provisioned MISP accounts — especially privileged ones — in case they hold empty-password hashes. Review authentication logs for successful logins against known directory-user email addresses using empty passwords.

Missing Authorization vulnerability in Drupal Data field allows Forceful Browsing. This issue affects Data field versions: from 0.0.0 to 2.0.13.

Authentication Bypass Using an Alternate Path or Channel vulnerability in Drupal CAPTCHA Protected Page allows Functionality Bypass. This issue affects CAPTCHA Protected Page versions: from 0.0.0 to 1.0.2.

Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") vulnerability in Drupal Address Suggestion allows Cross-Site Scripting (XSS). This issue affects Address Suggestion versions: from 0.0.0 to 1.0.25.

Insertion of Sensitive Information Into Sent Data vulnerability in Drupal DXPR Builder: The Best Editing (AI) Experience for Drupal allows Forceful Browsing. This issue affects DXPR Builder: The Best Editing (AI) Experience for Drupal versions: from 0.0.0 to 2.8.1.

Improper Handling of Case Sensitivity vulnerability in Drupal External Authentication allows Privilege Escalation. This issue affects External Authentication versions: from 0.0.0 to 2.0.13.

Server-Side Request Forgery (SSRF) vulnerability in Drupal Entity Share Websub allows Server Side Request Forgery. This issue affects Entity Share Websub versions: from 0.0.0 to 1.1.2.

Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") vulnerability in Drupal Entity Browser allows Stored XSS. This issue affects Entity Browser versions: from 0.0.0 to 2.16.0.

morgan is an HTTP request logger middleware for Node.js. In versions prior to 1.12.0, the internal helper that escapes log token values did not neutralize the Unicode line separator characters U+0085 (Next Line), U+2028 (Line Separator), and U+2029 (Paragraph Separator). An unauthenticated remote client can place these characters in an attacker-controlled log token, for example a Basic auth username surfaced through the remote-user token, so that Unicode-aware downstream log processing splits a single request log into multiple logical records. This is a log forging issue (CWE-117) and an incomplete-fix follow-up to CVE-2026-5078, which only addressed ASCII control characters. The issue is fixed in morgan 1.12.0, which extends the escaping set to cover these Unicode line separators. Upgrade to morgan 1.12.0 to remediate.

CVE-2026-13481 is an out-of-bounds read (CWE-125) in the IEEE 1588 PTP management-message parser of the Zephyr RTOS networking stack (subsys/net/lib/ptp/tlv.c), where the PTP_MGMT_TIME management id is cast to a 10-byte struct ptp_timestamp and read without first checking that the TLV data field is at least that long — the only management id in the switch missing this validation. An adjacent attacker on the local PTP segment can send a management message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and then byte-swap and write back 8 bytes beyond the validated data; the path is reachable whenever CONFIG_PTP is enabled. The attacker gains minor information exposure of adjacent bytes within the same message object and can corrupt the device's parsed management TIME value; there is no crash, no past-allocation memory corruption, and no reachable reference-count corruption. Only Zephyr builds with the PTP subsystem enabled are affected — a profile typical of industrial and telecom precision-timing deployments — and the Zephyr Project (the CNA) has published advisory GHSA-mh5r-jxh8-hxwx alongside the fix. Exploitation status: one public advisory/PoC reference exists, but there is no evidence of in-the-wild exploitation (EPSS 0.2%, not in CISA KEV).

Do: Upgrade to a Zephyr release that includes the upstream fix, which adds the missing guard — returning -EBADMSG when the TLV data is shorter than sizeof(struct ptp_timestamp) — in tlv_mgmt_post_recv(), and consult GHSA-mh5r-jxh8-hxwx for the exact fixed version for your branch. If patching is not immediately possible, disable CONFIG_PTP or restrict acceptance of PTP management messages to trusted adjacent peers. Given the low EPSS and absence of known in-the-wild exploitation this is not urgent, but exposed precision-timing deployments should prioritize the update.

hbs is an Express view engine that wraps Handlebars. Its registerAsyncHelper API bypasses Handlebars' automatic HTML escaping: an async helper returns an opaque placeholder during the first render pass, so the double-brace expression escapes only the placeholder, and after rendering hbs substitutes the placeholder with the raw callback return value without escaping it, across the cached, uncached, and layout render paths. An application that passes attacker-influenced data, for example user-supplied content from a database, into an async helper callback can therefore have arbitrary HTML and JavaScript injected into the server-rendered page, resulting in stored or reflected cross-site scripting. Versions 2.1.0 through 4.2.1 are affected, and the issue is fixed in 4.3.0, which HTML-escapes async helper output. Applications that intentionally emit raw HTML from an async helper can opt in explicitly with hbs.SafeString. Users should upgrade to 4.3.0.

GitPython's GitConfigParser contains a configuration-injection flaw (CWE-88/CWE-94) in its read-then-write round trip: multi-line values parsed from an on-disk config file using git's standard backslash-continuation syntax are decoded into Python strings with embedded newlines, and when the parser later rewrites the file, write_section() serializes them as a bare, unquoted newline-plus-tab continuation that real git parses as separate top-level config lines. The recently added UNSAFE_CONFIG_CHARS_RE safety guard only applies to values passed directly to set()/set_value()/add_value()/add_section(), never to values loaded from disk via _read(), so any unrelated write can turn a dormant value into a live directive such as core.hooksPath = <attacker-controlled path>. An attacker who can plant such a value in a config file that a GitPython-based application later rewrites gains arbitrary code execution, because git will execute the attacker's hook programs with the privileges of the user running GitPython. Developers, CI/CD systems, and pip-packaged tools that embed GitPython and rewrite git config files are affected, with GitPython 3.1.58 at HEAD confirmed vulnerable. No public PoC exists, it is not in CISA KEV, and EPSS assigns only a 0.4% probability of exploitation within 30 days, so no exploitation is currently known.

Do: Monitor GitPython for a patched release beyond 3.1.58/commit 9729ed3b (no fixed version is identified in the available data) and upgrade as soon as one is published. In the interim, avoid letting GitConfigParser rewrite config files that may contain multi-line (backslash-continuation) values, audit managed .git/config and related files for values with embedded newlines or unexpected trailing fragments like hooksPath, and restrict write access to those files to trusted principals.

tor before 0.4.9.9 was prone to an out-of-bounds write when parsing a consensus or detached signature with unexpected signature digest type. Impact is minor for most Tor roles, but potentially major for directory authorities. This is TROVE-2026-019.

libexpat before 2.8.4 lacks handler call depth tracking with custom encoding callbacks. Thus, a use-after-free can occur. NOTE: this is similar to CVE-2026-50219, CVE-2026-56131 and CVE-2026-56412.

GitPython before 3.1.58 contains a flaw (CWE-88) in its check_unsafe_options guard, which is meant to block unsafe git options while allow_unsafe_options is set to its default value of False. The guard can be bypassed by combining a single-character keyword argument with split_single_char_options=False, causing GitPython to emit a joined token that git itself parses as an --upload-pack option. An attacker who can influence the kwargs passed to guarded methods such as clone_from can therefore inject --upload-pack and achieve arbitrary OS command execution, despite the library's default safe configuration. Any Python application, service, or pipeline built on the pip-installed GitPython library that passes attacker-controlled or remotely influenced arguments into its git wrapper methods is affected. A public proof-of-concept reference exists via the project's GitHub security advisory (GHSA-wvpp-8hx9-p66j); there is no evidence of in-the-wild exploitation yet, and EPSS puts 30-day exploitation probability at roughly 0.6%.

Do: Upgrade to GitPython 3.1.58 or later via pip as soon as possible. Audit application code paths where user or remote input flows into kwargs of guarded GitPython methods (e.g., clone_from), and avoid combining split_single_char_options=False with single-character keyword arguments until patched. No in-the-wild exploitation is confirmed, but given the public advisory, prioritize updates for internet-facing services that wrap git operations.

MLflow versions prior to 3.15.0 contain a server-side request forgery flaw (CWE-918) in the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint. The webhook URL is validated only for the original request, but delivery follows redirects and re-resolves the hostname without pinning the validated address, letting an attacker redirect server-side requests to internal network services or cloud instance metadata endpoints. Because the endpoint returns response_status and response_body, attackers can read internal service responses and, per public reporting, steal cloud credentials and secrets from metadata services. Any self-hosted MLflow deployment is affected, with internet-exposed servers at the highest risk. Exploitation is confirmed in the wild: CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2026-08-19, and headlines report active attacks stealing cloud credentials; EPSS puts 30-day exploitation probability at 16.4% (97th percentile).

Do: Upgrade to MLflow 3.15.0 or later immediately, prioritizing any MLflow server reachable from the internet. Until patched, restrict network access to MLflow (especially the /api/2.0/mlflow/webhooks/{id}/test endpoint), place it behind authentication or a reverse proxy, and review webhook logs for unexpected test requests and cloud metadata endpoint access; rotate cloud credentials and secrets if compromise indicators are found. Federal agencies must apply vendor mitigations in accordance with CISA BOD 26-04 guidance or discontinue use if mitigations are unavailable.

GitPython versions before 3.1.54 contain an OS command injection flaw (CWE-78) in which the check_unsafe_options guard intended to block dangerous git options can be bypassed by smuggling git options inside single-character kwarg values. An attacker who can influence the option dictionaries passed to commonly used methods — clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive — can inject the --upload-pack parameter to execute arbitrary OS commands on the host. Successful exploitation yields remote code execution with the privileges of the Python process running GitPython (CVSS 4.0: 8.7, high). Any Python application, service, or CI/automation tooling built on affected GitPython versions where attacker-controlled data reaches these git option arguments is affected. No confirmed in-the-wild exploitation yet (not in CISA KEV, EPSS ~0.7%), but a public advisory and proof-of-concept reference exist, so weaponization is straightforward.

Do: Upgrade to GitPython 3.1.54 or later. Interim mitigation: audit all code paths that pass user- or attacker-controlled arguments or option dictionaries into clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive, and validate that option values (especially short/single-character kwargs) cannot smuggle extra git options such as --upload-pack. Review web applications and automation that invoke git via GitPython to confirm whether untrusted input reaches these parameters.