CVE WatchOct 19, 2026

CVE-2026-55644

Element X iOS is a Matrix iOS Client provided by Element. Element X iOS before version 26.05.0 fails to check the URL allowlist when parsing

CVSS

—

No CVSS

EPSS

—

KEV

—

Exploit Today

0-100

Published: Oct 19, 2026 · Last modified: Oct 19, 2026 · CWE-20

EPSS · 30d

Not enough EPSS history yet.

Technical description

Element X iOS is a Matrix iOS Client provided by Element. Element X iOS before version 26.05.0 fails to check the URL allowlist when parsing io.element.call://. If an attacker is able to trick the user into opening a maliciously crafted io.element.call:// URL, they are able to load an attacker-controlled origin inside the call screen's WKWebView which will be granted device microphone and camera permissions (provided the user has previously granted these permissions to Element X iOS). This issue has been patched in version 26.05.0.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-92287—

—

——0Pass-through of unvalidated KMS URLs to KMS clients in Apache C++ Parquet and PyArrow versions 4.0.0 to 25.0.1. This affects users who read Parquet files and configure Parquet decryption properties with a KmsClient implementation. On the reader side, the KMS URL can be application-controlled (specified in the KmsConnectionConfig) or file-controlled. If the user does not leverage application control for this parameter, a file-controlled KMS URL is forwarded to a pluggable KmsClient implementation. If the KMS implementation does not perform host validation and makes use of the provided KMS URL, a KMS token can be sent to a malicious host set by an attacker in the file. Users are recommended to upgrade to version 26.0.0, which disables this behavior by default and requires that users opt-in to it by enabling the read_kms_url flag in the DecryptionConfiguration. Users of affected versions are recommended to either specify the KMS URL in the KmsConnectionConfig when reading files, or ensure any KmsClient implementations validate received KMS URLs. Users that opt-in to file-controlled KMS URLs in version 26.0.0 and later must ensure KmsClients validate KMS URLs.3h CVE-2026-1101804.8 MED

—

——0fast-uri is a dependency-free RFC 3986 URI parser and serializer for Node.js. In versions from 2.4.2 through 2.4.7, from 3.1.3 through 3.1.8, and from 4.0.1 through 4.2.2, for HTTP-family schemes the canonicalizeHost() function passes the parsed host to the WHATWG URL parser and adopts its hostname without checking that the parser consumed the entire input as a host, so the authority can be silently rewritten: data before an at-sign is dropped and tab, carriage-return, and line-feed characters are stripped, with no error reported. An application that enforces host-based policy such as denylists, loopback filtering, redirect validation, or outbound proxy routing on one representation can then see the canonical host diverge from what it checked, allowing traffic to be steered to an unintended destination. The issue is fixed in fast-uri 2.4.8, 3.1.9, and 4.2.3, and users should upgrade to one of these versions or later. As a workaround, reject an authority that contains more than one at-sign or any tab, carriage-return, or line-feed before calling fast-uri, or treat any non-empty parse error as fatal and compare hosts only from the same parse result.5h CVE-2026-112991—

—

——0The html_to_markdown expansion module in MISP Modules contains a server-side request forgery (SSRF) vulnerability in its is_safe_url() URL validation function. The BLOCKED_RANGES list used to reject unsafe destination addresses was incomplete, omitting several critical IP address ranges. Specifically, the following ranges were not blocked: 0.0.0.0/8 (unspecified, which routes to loopback on Linux), 100.64.0.0/10 (carrier-grade NAT per RFC 6598), ::/128 (IPv6 unspecified), fc00::/7 (IPv6 Unique Local Addresses), and fe80::/10 (IPv6 link-local). The existing list only covered IPv4 loopback (127.0.0.0/8), RFC 1918 private ranges, IPv4 link-local (169.254.0.0/16), and IPv6 loopback (::1/128). An authenticated user with the ability to create or modify MISP attributes that trigger the html_to_markdown expansion module could supply URLs pointing to these unblocked internal address ranges. Because the module fetches the URL server-side to convert HTML content to Markdown, the request is made from the MISP server's network context. This allows an attacker to probe and read responses from internal services, carrier-grade NAT infrastructure, or link-local endpoints that would otherwise be unreachable from external networks. IPv4-mapped IPv6 forms (e.g., [::ffff:0.0.0.0]) also bypassed the existing checks. The security impact is primarily confidentiality: an attacker can read data served by internal services reachable from the MISP server. The MISP instance itself is not compromised, but it is abused as a proxy to access otherwise restricted network resources.5h CVE-2026-853146.5 MED

—

——0Improper Input Validation vulnerability in Apache Camel Mail component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. CVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders("mail.smtp*") before any mail producer.15h CVE-2026-853124.8 MED

—

——0Improper Input Validation vulnerability in Apache Camel Core component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders("Long-Running-Action") on every consumer that accepts messages from an untrusted sender.15h CVE-2026-852496.5 MED

—

——0Improper Input Validation vulnerability in Apache Camel Tika component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Tika producer mapped every metadata key parsed out of the submitted document onto the Exchange as a header, with no filter applied. Document metadata is attacker-controlled content: the party that supplies the file chooses the metadata keys it carries. A crafted document could therefore set Exchange headers that the rest of the route depends on, including headers in the Camel namespace such as CamelFileName, which downstream components use to decide where content is written. The pattern is the same header-injection class as the consumer advisories published previously, reached here through parsed file content rather than through a protocol header. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing. For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders("Camel*") before any component that acts on those headers.15h