Information Disclosure
Monthly
In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: clamp quantum and initial_quantum in change path The fq change path accepts TCA_FQ_QUANTUM in [1, INT_MAX] and TCA_FQ_INITIAL_QUANTUM up to INT_MAX, while fq_init() already clamps to [1, 1<<20]. A user can override the init clamp via tc qdisc change, restoring the small-quantum deficit spin that the init clamp prevents. Narrow iq_range.max to 1<<20 so TCA_FQ_INITIAL_QUANTUM is rejected at parse time. Clamp TCA_FQ_QUANTUM to [256, 1<<20] in fq_change() and fq_init() quantum to [256, 1<<20] for tiny-MTU devices. Conditions to recreate the bug: CONFIG_NET_SCH_FQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq tc qdisc change dev dummy0 root fq quantum 1 stab data 32768 size_log 15 cell_log 0
Cleartext exposure of origin credentials in AsyncHttpClient (AHC) 2.0.0-2.16.0 and 3.0.0-3.0.11 occurs when a Java application reaches an HTTPS origin through an HTTP CONNECT proxy while using preemptive origin authentication: the library attaches the origin's Authorization header - Basic or Digest credentials, plus per-connection NTLM/Kerberos/SPNEGO tokens - to the plaintext CONNECT request before any TLS tunnel exists, so the proxy and any observer on the client-to-proxy hop can read credentials meant only for the origin. The vulnerability is rated CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but a high attack-complexity qualifier, because exploitation requires the specific non-default combination of a CONNECT proxy, preemptive origin authentication, and an adversary positioned on that network segment; authentication requirements are not confirmed from the supplied vector beyond PR:N, and there is no public exploit identified at time of analysis. Vendor-released patches are 2.16.1 and 3.0.12, and because 3.0.12 is itself affected by a separate Digest-to-Basic downgrade flaw (GHSA-rqf5-2wxv-rjf4), 3.0.13 is the recommended target on the 3.x line.
Credential disclosure in AsyncHttpClient (Java) allows a client configured with a client-wide Realm via config.setRealm(...) and with redirect following enabled to leak Basic, Digest, Negotiate, or NTLM credentials to an attacker-controlled origin. When a cross-origin or scheme-downgrade redirect clears the per-exchange realm, the authentication interceptor in Interceptors.java falls back to config.getRealm() and re-attaches the client-wide credentials; if the attacker's target then answers HTTP 401, the client sends those credentials or tokens to that foreign origin. Affected releases are 2.14.5 through 2.16.0 and 3.0.9 through 3.0.11, fixed in 2.16.1 and 3.0.12; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the flaw is conditional on the specific client-wide Realm configuration, redirect following, attacker-influenced redirect, and a 401 response (AC:H per the assessed vector).
MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9 can be tricked into transmitting a locally selected file to a rogue or man-in-the-middle database server even when the allowLocalInfile option is explicitly set to false, because the connector processes a server-initiated LOCAL INFILE packet (0xfb) without honoring that setting. The exposure is narrow: the attacker can only receive the exact file the application already chose to load via a LOAD DATA LOCAL INFILE COM_QUERY, cannot redirect the request to an arbitrary path, and gains nothing unless the application organically loads sensitive data over an untrusted connection - so this is a low-severity (CVSS 3.7), highly conditional information-disclosure issue rather than a widespread threat. The vulnerability is unauthenticated at the network layer per the vector (PR:N) but requires high attack complexity (AC:H) and control of the server or the connection path; no public exploit code has been identified at time of analysis, and the flaw is fixed in the four versions listed above.
Information disclosure in Steeltoe's Management Endpoint actuator (Steeltoe.Management.Endpoint) prior to 4.3.0 allows an unauthenticated remote attacker who can reach the exposed /actuator/httpexchanges endpoint to harvest secrets that were previously captured in recorded request query strings - OAuth and password-reset tokens, API keys, and signed-URL signatures - because MaskedUri only redacts URI user-info and never inspects the query string. The same recorded URIs are written by the Steeltoe.Management.Endpoint.Actuators.HttpExchanges DEBUG logger, giving anyone with log access a second disclosure channel. Exploitation is config-gated (IncludeQueryString must be enabled, the endpoint must be explicitly exposed, and prior traffic must actually have carried query-string secrets), scoring CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N); no public exploit identified at time of analysis, and the issue is remediated in Steeltoe 4.3.0.
Mattermost Desktop App versions up to and including 6.2.2.0 fail to validate the URL scheme when deciding whether a link points to an internal server resource, so a network-positioned attacker who can intercept and downgrade the connection can make the client open a plugin popout window over an insecure (non-TLS) connection. Exploitation is narrow: it requires a man-in-the-middle position capable of forcing the scheme downgrade, an authenticated user of the affected client (PR:L per the CVSS vector), and that user clicking a crafted internal link (UI:R), which is why the vendor and independent scoring both land in the low range (vendor 2.6; independently assessed AV:A/AC:H). There is no indication of active exploitation and no public exploit code identified at time of analysis; the realistic impact is limited to integrity of the content rendered in the popout window, with no confidentiality or availability effect.
Dell SmartFabric Manager installations running versions earlier than 2.2.1 can disclose limited information to a low-privileged attacker who already holds a valid account and can either reach the management interface over the network or induce a legitimate user to perform an action. The flaw is rated CVSS 3.1 3.5 (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N), so it requires authentication plus user interaction and results only in low confidentiality impact with no integrity or availability effect - not an unauthenticated, default-configuration remote compromise. There is no evidence of active exploitation (the issue is not in CISA KEV), no public proof-of-concept identified at time of analysis, and no independent EPSS signal was supplied; this is a genuinely low-priority issue by every available signal.
Unauthenticated server-side request forgery in Nuxt OG Image (the npm package nuxt-og-image) 6.0.2 through 6.6.x allows any remote attacker who can reach a deployed Nuxt site to make the server issue arbitrary outbound GET requests by supplying a crafted fonts[].path value to the public /_og/d/** image-generation route. Exploitation works against the module's documented defaults (security.strict = false, security.secret = "", restrictRuntimeImagesToOrigin = false), and the response is blind: the outer HTTP status is 500 when the internal target answers with 2xx and 200 when it fails, giving a usable oracle to enumerate live loopback, RFC1918, link-local and cloud-metadata services, while slow targets can also tie up OG image render workers for the configured fetch/render timeouts. No public exploit identified at time of analysis (no KEV listing); vendor-released patch: 6.7.0.
Improper TLS certificate validation in Dell OpenManage Server Administrator (OMSA) managed-node builds prior to 11.1.0.3 allows an unauthenticated attacker who already occupies an adjacent-network position (same LAN or management VLAN) to man-in-the-middle OMSA traffic and accept a forged or invalid server certificate, resulting in disclosure and tampering of management data. The CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, score 6.8) confirms adjacent access and high attack complexity are required but no credentials or user interaction are needed once a MITM foothold exists; the issue is limited to the local management plane and cannot be triggered from the public internet. No public exploit code has been identified and the flaw is not in CISA KEV, so this is a moderate-real-risk hardening issue rather than an emergency, with the primary fix being the vendor release 11.1.0.3.
Unauthenticated attackers can retrieve hidden catalog entities from Vendure's publicly accessible Shop API by setting the filterOperator argument to OR, which causes the mandatory visibility guard to be OR-combined with the caller's own filters instead of AND-combined. The flaw affects the npm package @vendure/core in all versions from 1.0.0 up to (but not including) 3.6.5 and exposes disabled products and private collections or facets through the products, collections, and facets list queries. CVSS 3.1 is 5.3 (Medium, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), consistent with read-only information disclosure; no public exploit identified at time of analysis, although the upstream fix commit and its regression tests are publicly visible.
Chunked-transfer request smuggling in Sanic allows a remote unauthenticated attacker to plant a hidden second HTTP request inside the trailer-part of a chunked request, which Sanic then parses and routes as a genuine backend request on the same keep-alive connection. Affected versions are all releases before 24.12.1 and the 25.12.0 release (fixed in 24.12.1 and 25.12.1); the defect triggers on default configuration, with CVSS 3.1 scoring 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L) reflecting a request-boundary integrity failure rather than direct data compromise. A verified proof-of-concept is included in the upstream advisory showing a single TCP payload yielding two responses (a 405 for the outer POST and a 200 for a smuggled GET), meaning publicly available exploit code exists; the practical risk is highest when Sanic sits behind a reverse proxy, CDN, or load balancer that disagrees with Sanic on request boundaries.
Untrusted JavaScript running inside a vm2 sandbox before version 3.11.2 can reach the host-side internal state object via globalThis['VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL'], disclosing sandbox internals that were supposed to be invisible to guest code in the npm package vm2. The issue is a re-bypass of the earlier advisory GHSA-wp5r-2gw5-m7q7, and a short working proof-of-concept is published in the vendor advisory GHSA-2cm2-m3w5-gp2f, so publicly available exploit code exists; no CISA KEV listing appears in the supplied intelligence and no EPSS value was provided. The CVSS 4.0 base score is 6.9 with a confidentiality-only impact (VC:L, VI:N, VA:N, SC:N, PR:N, UI:N), consistent with the independent assessment that this is a genuine but low-severity information disclosure with no demonstrated code execution, integrity, or availability effect; the unauthenticated PR:N rating reflects the vector, while in practice the attacker must already be able to execute code inside the vm2 trust boundary (an application that embeds vm2 and runs attacker-controlled scripts).
Absolute host filesystem path disclosure in vm2 3.11.0 through 3.11.6 allows attacker-supplied JavaScript running inside a vm2 sandbox to force the host-realm source transformer to throw a SyntaxError (for example via eval with malformed source) and then read the resulting error's .stack property, which the bridge forwards to the host-realm formatter. Default new VM() and new NodeVM() configurations are affected with no special options, and the leak persists even when string eval is disabled, because the host-side transformer throws before eval is handled. Only information disclosure results - absolute paths from vm2, Node.js internals, and the embedding application's source tree plus host function names - with no write, no code execution, and no public exploit identified at time of analysis; the CVSS 4.0 score of 6.9 reflects the scope change and low confidentiality impact rather than a high-severity outcome.
Information disclosure in vm2 through version 3.11.7 allows sandboxed Node.js code to read the host process's call stack metadata: NodeVM exposes the host util module as an unfiltered shallow copy and also exposes the deprecated sys alias, and on Node.js 22.9 or later this hands sandbox code util.getCallSites(), which returns absolute file paths, function names, and line numbers for vm2 bridge internals and the embedding application's entrypoint. Remote attackers are unauthenticated (CVSS PR:N), but exploitation requires the host application to actually execute attacker-controlled JavaScript inside NodeVM and to be running Node.js >= 22.9; the leak is read-only and grants no code execution or write access. Vendor-released patch: vm2 3.11.8. No confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis.
The audit-log add-on in AshAuthentication stores pseudonymised client IP addresses using an unkeyed SHA-256 over a salt concatenated with the IP, truncated to 16 hex characters, so anyone who can already read the audit store can reverse those values back to the original addresses. Exploitation requires two explicit prerequisites: ip_privacy_mode must be set to :hash (the DSL default is :none, so this is an opt-in), and the attacker must already hold read access to the audit log via a database dump, backup, replica, or reader account. Reversal is trivial when the salt is left at the library's published fallback constant 'default-salt-change-in-production', which is used silently with no warning; even a properly configured salt only reduces the problem to 'that salt must leak', after which exhaustive enumeration over the 2^32 IPv4 space is cheap. Per the authoritative assessment this is a low-priority information-disclosure issue (assessed CVSS 3.1 1.8, CWE-760) affecting only client IP addresses with no integrity or availability impact; no public exploit identified at time of analysis, and vendor-released patches exist in 4.15.0 and 5.0.0-rc.14.
The audit_log add-on in the Elixir library AshAuthentication (ash_authentication) writes the full actor record into each audit entry's extra_data field, so the user's hashed_password digest is stored alongside the audit trail in versions from 4.12.0 up to but not including 4.15.0, and from 5.0.0-rc.0 up to but not including 5.0.0-rc.2. There is no network-facing or attacker-triggered disclosure path: entries accumulate from ordinary authenticated activity controlled by benign code, and an attacker's own requests only deposit the attacker's own digest, so exploitation requires that the attacker already hold independent read access to the audit store (database credentials, an audit role, a backup, or a log shipper). The result is exposure of password hashes that support offline cracking of every active account whose actions were audited; the vector is local, high complexity, and privileged (per the assessment PR:H), making this a log-hygiene/defense-in-depth issue rather than an actively exploited one - no public exploit code or CISA KEV entry has been identified at time of analysis, and vendor patches are available.
Server-side request forgery in the MISP sachertortephp library (a fork of CakePHP) lets any code that calls Xml::build() with the readFile option set to false still trigger an outbound HTTPS fetch whenever the supplied input string starts with 'https://', because a missing pair of parentheses in the gating condition makes the https:// branch independent of the readFile flag. The application then parses the remote response as XML and may hand it back to the caller, exposing internal-only services or attacker-chosen external endpoints to data disclosure, with the bundled HttpSocket configuration following up to 10 redirects to widen reachable targets. Exploitation is authenticated in practice (CVSS:4.0 PR:L / assessed CVSS:3.1 PR:L) and requires a reachable host-application code path that passes attacker-influenceable data to Xml::build(); no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV). The http:// branch is correctly gated and is not exploitable - only the https:// scheme bypasses the intended suppression of remote reads.
Password cracking in admin3 3.0.0 and earlier allows anyone who obtains the application's credential database to recover user plaintext passwords offline, because stored credentials use single-round MD5 salted only with the username and no key-derivation function. The flaw does not grant database access by itself - it requires a prior compromise (database breach, SQL injection, exposed backup, or insider/privileged access, reflected by the CVSS PR:H prerequisite), but once that precondition is met, cracking is trivial on commodity hardware; publicly available exploit code exists. With a vendor score of 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) and no confirmed active exploitation, this is a genuine but conditional, low-to-moderate risk that amplifies the impact of an upstream data exposure rather than creating one.
Disabling or locking a user account in admin3 through 3.0.0 does not invalidate that user's existing bearer tokens, so a previously authenticated user retains full access with their original permissions after the account is disabled. The root cause is twofold: the AuthInterceptor never re-checks the user's locked status on subsequent requests, and LocalSessionManager resets session expiry on every request, so a pre-existing token never lapses through inactivity. Publicly available exploit code exists (a proof-of-concept account-lockout-bypass script), and exploitation requires that the attacker already held a valid token issued while their account was enabled (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, CVSS 5.4) - a rogue-insider or post-disable persistence scenario rather than unauthenticated compromise. Confirmed actively exploited (CISA KEV) status is not indicated by the available data, and there is no privilege escalation beyond the disabled account's original permission set.
Information disclosure in Dell OpenManage Server Administrator (OMSA) managed nodes running versions prior to 11.1.0.3 stems from use of a broken or risky cryptographic algorithm in the product's network communication, which an unauthenticated remote attacker could leverage to expose limited information (CVSS 3.1: 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N). The high attack-complexity metric indicates that realistic exploitation requires a privileged man-in-the-middle position on the path to the managed node or offline cryptanalysis of captured management traffic, not a single direct request, and there is no integrity or availability impact. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, consistent with the independent assessment that this is a genuinely low-priority exposure typically confined to internal or out-of-band management networks. Affected platforms include the Windows managed-node patch and managed-node builds for RHEL 8.10, RHEL 9.4, SLES 15, and Ubuntu 22.04.
Acer System Monitoring, the WebSocket-enabled helper bundled with NitroSense and PredatorSense on Acer Nitro and Predator laptops, is configured to bind its listener to all network interfaces rather than to localhost, so any host that can reach the port on the same network segment can talk to the service without authentication or user interaction. The consequences are limited - the assessed impact is confined to low-level confidentiality, integrity and availability effects (minor telemetry exposure or restricted interaction with the service) - and the issue is compounded only mildly by the fact that the utility must actually be installed and running on a reachable machine. This is a low-priority finding: no public exploit code exists, no confirmed active exploitation has been reported, and the vendor vector (CVSS 4.0 score 2.7) plus an independent assessment (CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) agree that practical exposure is realistically limited to an attacker on the same LAN, hotel or office Wi-Fi.
Authenticated WordPress users holding the Author role or above can export every comment stored on a site running the Comments Import & Export plugin before version 2.5.4, because the export routine performs no moderate_comments capability check and does not scope results to the caller's own content. Exposed data includes commenter email addresses, IP addresses, unapproved comment bodies and comment meta. Publicly available exploit code exists, but the weakness is gated behind a valid Author-level credential, so exposure is concentrated on multi-author sites or installations that permit author-level self-registration; the impact is confidentiality-only and bounded.
Forged email tracking links in the Newsletter WordPress plugin before 9.3.8 let an unauthenticated attacker who first recovers the plugin's weakly generated signing key offline obtain any subscriber's session token and then read or modify that subscriber's stored personal data. The root cause is a signing key generated with insufficient entropy combined with tracking links signed by an unkeyed hash, which makes offline key recovery practical rather than dependent on a leaked secret; publicly available exploit code exists. Rated CVSS 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N), the issue is real but moderate: exploitation requires the tracking feature to be in use and a successful offline key-recovery step, and the impact per forged link is bounded to a single subscriber with no code execution or availability loss.
Information disclosure in the LearnPress WordPress plugin before 4.4.7 allows unauthenticated remote attackers to retrieve the correct answer for every option of a quiz question, along with the instructor's accompanying explanation, from any course configured to be taken without enrolling. Exploitation is remote and requires no authentication, no user interaction and no special client, but it is gated by a non-default course setting (enrollment-free access), which is why the vendor and our assessment rate the attack complexity as high and the overall CVSS at 3.7. Publicly available exploit code exists (WPScan published the vulnerability write-up), though there is no indication of confirmed active exploitation in CISA KEV; the practical harm is limited to quiz answer-key and explanation disclosure, with no credential, PII or write-access impact.
Double decoding in the Canva Desktop deeplink handler (versions before 1.125.0) lets an unauthenticated attacker who convinces a user to open a crafted custom-URI deeplink cause the application to load arbitrary same-origin content within that user's session. The flaw (CWE-174) yields limited integrity impact only, with no confidentiality or availability effect, and exploitation requires user interaction (UI:R). No public exploit code or confirmed active exploitation has been identified at time of analysis (no CISA KEV entry; no EPSS score supplied), and the vendor has released a fix in v1.125.0.
Unauthenticated attackers can write to the WordPress database option ai1wm_auth_header in All-in-One WP Migration and Backup versions up to 7.110 by sending a crafted Authorization: Basic header to admin-ajax.php or admin-post.php, because the plugin's Ai1wm_Main_Controller::init() method on the admin_init hook reads PHP_AUTH_USER and PHP_AUTH_PW without authentication or nonce checks and stores them as reversible base64. This integrity-only issue (CVSS 5.3) allows overwriting the stored credential with attacker-chosen values, and in environments using WordPress Application Passwords, legitimate credentials sent to /wp-admin/ are silently captured into the database, though extracting them requires separate read access. No public exploit code or active exploitation has been identified at time of analysis.
Risk cannot be meaningfully assessed for CVE-2026-82374 because the published record contains no description, no CVSS score or vector, no CWE classification, no CPE data, and no reference set; the sole available signal is that the record was reported by the vendor Ubuntu. With no affected package, version range, deployment mode, or attack vector specified, it is not possible to state who is affected or what an attacker could achieve, and no public exploit identified at time of analysis. The CVE is not associated with CISA KEV status or an EPSS score in the supplied intelligence, so no conclusion about active exploitation or likelihood can be drawn.
An unspecified defect in an as-yet-unidentified Ubuntu package is tracked as CVE-2026-82373, but the record carries no description, no CVSS vector, no CWE classification, and no patch reference, so the affected component, attack surface, and impact cannot be established. The only confirmed signal is provenance: the entry was reported by the Ubuntu security team through its vendor CVE tracker. No public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation, so risk cannot be meaningfully assessed from the provided data.
Local privilege escalation in the NetworkManager iodine VPN plugin (network-manager-iodine) lets an authenticated local user obtain code execution as root through option confusion in the root-privileged nm-iodine-service. A user who is permitted (typically via polkit for an active session) to create or edit an iodine VPN connection can supply a connection property value that iodine's command-line parser interprets as an option flag instead of data, producing behaviour that runs while the service is still root and before iodine drops privileges to an unprivileged user. Exploitation requires local access plus an installed, configured plugin, and no public exploit was identified at time of analysis; the assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (high confidentiality, integrity and availability impact, scope unchanged). Note that no CVSS vector, CWE, EPSS, KEV, SSVC or POC signal was supplied in the source data, so severity here derives from the independent assessment rather than vendor scoring.
Local privilege escalation in the NetworkManager VPNC plugin (network-manager-vpnc) lets a user who can create or modify a VPN connection profile inject newline/control characters into the generated vpnc configuration, causing a rogue directive such as 'Password helper' to be written and subsequently executed by the privileged helper when the connection is activated. The record is explicitly identified as an incomplete fix of CVE-2018-10900, meaning the original newline-injection vector was not fully neutralized, and exposure is limited to Linux hosts where the optional VPNC plugin is installed and the attacker already holds local rights to edit VPN settings. The provided intelligence contains no CVSS score, CWE, EPSS estimate, KEV listing, or POC indicator, so no public exploit identified at time of analysis and the actual risk depends on local privilege boundaries rather than remote reachability.
Attacker-influenced connection profile data can be routed into pppd's root-context pty/shell invocation in the ppp package (reported by Ubuntu), potentially letting a local user obtain code execution with the privileges of the pppd process. Our independent assessment scores this CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - local access is required, a connection must be initiated, and the target must actually use pppd for PPP/DSL/dial-up/mobile-broadband/VPN links, so exploitability is limited by how niche PPP is on modern systems; exploitation is not passive against a default configuration. No CVSS score, no CVSS vector and no CWE were supplied with the vendor report, there is no vendor-released patch identified at time of analysis and no public exploit identified at time of analysis. The exact privilege level required is not confirmed from the input, though the assessed vector implies an authenticated local user (PR:L).
Squid proxy software is affected by CVE-2026-62846, an issue tracked under the vendor's SQUID-2026:9 advisory identifier and reported into this dataset by the Ubuntu security team. No CVSS score, CVSS vector, CWE classification, or free-text technical description was supplied with the record, and the independent assessment concludes that risk cannot be meaningfully scored from the available input; therefore the specific impact, attack vector, and authentication prerequisites of this CVE remain unconfirmed. There is no indication of confirmed active exploitation (no CISA KEV entry) and no public exploit code identified at time of analysis, though the absence of exploit signals here reflects missing intelligence rather than a positive finding of unreachability.
Squid caching proxy is affected by an uncharacterized security issue tracked as CVE-2026-61642 and referenced upstream only as '[SQUID-2026:6]', surfaced through Ubuntu's distributor advisory ingestion. The provided data contains no vulnerability description text, no CVSS score or vector, and no CWE, so the impact, attack vector, and required proxy deployment mode (forward or reverse) cannot be determined; no public exploit code identified at time of analysis. Because exploitation prerequisites are unconfirmed and risk cannot be meaningfully scored, defenders running Squid - particularly Ubuntu-packaged Squid - should retrieve the upstream SQUID-2026:6 advisory and the corresponding Ubuntu security notice to establish affected versions and exposure before treating this as actionable.
Sandbox bypass in the n8n Git node lets an authenticated member-level user read git repository objects located outside the path enforced by N8N_RESTRICT_FILE_ACCESS_TO. n8n validates a relative remote URL against the configured repositoryPath, but git is then executed with that directory as its working directory and walks up to the enclosing repository's top level, where it resolves the identical URL string from outside the sandbox; a subsequent fetch or pull merges the external repository's objects into the attacker's own repository, from which the contents can be read back. Versions before 1.123.76, 2.37.7, and 2.38.2 are affected; no public exploit code has been identified at time of analysis, and the confidentiality-only impact (CVSS 4.0 base 5.3, assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) is neutralized by upgrading or by disabling the Git node.
Credential leakage in the rmcp Rust SDK (the official Rust SDK for the Model Context Protocol) prior to 2.1.0 allows an attacker who controls or compromises an MCP endpoint to harvest API keys and tokens from victim clients. StreamableHttpClientTransport builds its default reqwest HTTP client with automatic redirect following and replays caller-supplied StreamableHttpClientTransportConfig.custom_headers on cross-origin 307/308 redirects without marking them sensitive, so secrets such as x-api-key headers are forwarded to the redirect target where the attacker can capture and reuse them. The issue is not actively exploited per available intelligence, no public exploit code was identified at time of analysis, and exploitation is condition-gated: it requires a client that (a) runs a pre-2.1.0 version, (b) places secrets in custom_headers rather than the standard Authorization path, and (c) talks to a malicious or compromised MCP server, which is why the assessed vector carries high attack complexity and limits impact to confidentiality (CVSS 6.8, AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N, CWE-200). A vendor patch is available in rmcp 2.1.0.
Cross-tenant data exposure on the djust live WebSocket path affects installations before 1.0.7 that use host-, subdomain-, or domain-based TenantResolvers for multi-tenancy. Because the request rebuilt by handle_mount and ViewRuntime._build_request carries no client Host, get_host() falls back to "testserver", so the tenant resolves to None on the live path even though the ordinary HTTP path resolves it correctly; with STRICT_MODE=False the tenant-scoped managers then return unscoped rows and an authenticated user can read other tenants' data. With the default STRICT_MODE the identical flaw only yields empty querysets (broken tenancy, no disclosure). No public exploit code exists and there is no confirmed active exploitation; EPSS/KEV data were not provided, and the CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N, 6.3) reflects the high attack complexity and the dependency on an explicit STRICT_MODE=False configuration.
Information disclosure in the djust Python WebSocket framework before 1.0.7 causes Django Model instances assigned to public (non-underscore) view attributes to be serialized to the browser with no sensitive-field denylist, exposing fields such as the password hash, is_staff/is_superuser privilege flags, tokens, and other PII inside the render payload sent to the client. Exploitation requires authenticated access to a view that assigns a full model to a public attribute (CVSS:3.1 AV:N/PR:L), and the resulting impact is confidentiality-only but rated High (C:H/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Prototype pollution in the unflatten helper of Builder.io Gen2 SDKs (the @builder.io/sdk-react, sdk-vue, sdk-svelte and sdk-solid packages at or below 5.2.11, and sdk-angular, sdk-react-nextjs and sdk-qwik at or below 0.25.13) lets unauthenticated remote attackers poison Object.prototype in a victim's browser by luring the victim into opening a crafted preview link whose builder.userAttributes query parameters carry __proto__ or prototype segments. Exploitation is not automatable against a passive server - it hinges on user interaction (UI:P), because the SDK must actually be running in the victim's browser when the malicious URL is processed, and real harm (DOM XSS, client-side logic tampering, denial of service) only materializes if downstream application code reads the polluted inherited properties. No CISA KEV entry and no public exploit code were identified at time of analysis, and the independent assessment rates real-world risk as moderate-to-low.
Remote, authenticated administrators of Cisco Identity Services Engine (ISE) can escalate from the web management interface to write access on the appliance's underlying operating system by sending a single crafted HTTP request, and Cisco confirms root is easy to reach from that primitive, making the practical outcome full device compromise. The flaw is improper restriction of resource/file names (CWE-641) in the ISE management web/API layer, reachable over the network with no user interaction but requiring valid administrative credentials (CVSS 3.1 PR:H), so it is a post-authentication escalation path rather than a pre-auth entry point. Cisco's published base score of 4.9 (Medium) understates the outcome - the vendor assigned a High Security Impact Rating for exactly this reason, and our independent assessment raises confidentiality, integrity and availability impact to High; no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV.
OpenTelemetry-Go versions 1.5.0 through 1.44.0 can write sensitive collector configuration into an application's own logs when the application explicitly opts into internal diagnostic logging through otel.SetLogger at Info verbosity: the TracerProvider created event serializes span processor, exporter, and client configuration, exposing OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. Anyone able to read those logs - local files, aggregated log stores, or a SIEM - can reconstruct internal collector topology and can recover credentials or tokens where operators embedded them in Zipkin URL user-info or query strings. The vendor CVSS 4.0 base score is 2.0 and no public exploit identified at time of analysis; note that OTLP authentication headers, TLS key material, and span payloads are never written by this path, and default OpenTelemetry configurations that do not install a logger are unaffected because the default logger does not emit the diagnostic event.
An out-of-bounds read in GPAC 26.08-DEV (the wait_for_header_and_parse routine in src/utils/downloader.c) can disclose memory contents or crash the process when the downloader parses a crafted or empty Content-Range value in an HTTP response header. The victim must actively initiate a download from a malicious or man-in-the-middle server for the malformed header to reach the parser; the vulnerable code path is in GPAC's generic HTTP/fetch machinery rather than a media-decoding path, and the consequence is limited to information disclosure or a crash - no write primitive or code execution is demonstrated. Publicly available exploit code exists (the issue is tracked publicly on the GPAC GitHub project) but the flaw is not confirmed actively exploited (CISA KEV), and the assessed impact is low on both the availability and confidentiality axes.
Information disclosure in the Tanium Discover module allows an authenticated console user to read data they should not have access to, with the vendor confirming the flaw has been addressed. The vulnerability requires network reachability and a valid low-privilege Tanium session (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) but no user interaction, and it affects only organizations that have licensed and deployed the optional Discover component. Impact is confined to confidentiality - there is no integrity or availability effect - and no public exploit code or confirmed active exploitation has been identified at time of analysis.
Clear-text logging in Arista EOS with the gRPC Network Packet Sampling Interface (gNPSI) enabled can expose gNPSI client credentials to authenticated users who can read local or remote accounting logs. Affected devices are those running EOS with the non-default, opt-in gNPSI feature configured; exploitation requires an already-authenticated user with log access and specific conditions under which the credentials are written in clear text. This is a moderate-severity information-disclosure issue (vendor CVSS 4.0 score 6.0), not remote code execution or unauthenticated access, and no public exploit has been identified at time of analysis.
Denial of service in HP's HPLIP (HP Linux Imaging and Printing Software) printing stack is reachable when a physically-present attacker supplies specially crafted input that triggers a CWE-191 integer underflow, crashing or hanging affected components; the scored CVSS:3.1 vector (AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) limits impact to availability only, with no confidentiality or integrity loss. The physical attack vector (direct hardware/USB or local physical access) is the dominant gating factor and rules out remote or network-based exploitation, and no public exploit has been identified at time of analysis. HP has stated that it identified and remediated the underlying issues, so a vendor fix is available per advisory hpsbpi04151, though the specific affected and fixed version ranges are not enumerated here and must be confirmed against that bulletin. Overall this is a genuine but low-priority issue: real availability impact, but exploitation requires an attacker to already have hands on the machine.
Cleartext disclosure of peer VRRP authentication credentials in Arista EOS log output allows an authenticated, privileged user - or anyone able to read a system receiving forwarded agent trace logs - to recover the shared secret that authenticates VRRP advertisements, without needing any presence on the VRRP network segment itself. The defect applies to EOS platforms configured with authenticated VRRP; exploitation requires high-privilege access to the switch's agent trace logs or to a downstream log collector, and the resulting impact is confidentiality-only (CVSS 4.0 base 2.1; our independent assessment rates it CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, i.e. PR:H and C:L). No public exploit code and no confirmed active exploitation were identified at time of analysis; this is a low-priority log-hygiene issue whose only notable edge over routine secret-in-log bugs is that the leak escapes the on-link boundary normally assumed for VRRP secrets.
Denial of service in HP Linux Imaging and Printing Software (HPLIP) can be triggered by a physically present attacker who supplies crafted input via a local device or print/scan job, exploiting improper array index validation (CWE-129). Although HP's advisory bundles several vulnerabilities that could potentially enable a broader range of impacts, the specific vector for this CVE limits the effect to availability (system crash or service disruption) with no confidentiality or integrity impact. No public exploit code or active exploitation has been identified at time of analysis, and the primary prerequisite is physical access to the target system.
Command injection (CWE-78) in HP's HPLIP (HP Linux Imaging and Printing) software enables an unauthenticated local user to execute commands or modify files with high integrity impact (VI:H) after active user interaction, matching HP's CVSS 4.0 score of 6.8 (AV:L/AC:L/PR:N/UI:A/VC:L/VI:H/VA:L) and the independent CVSS 3.1 assessment (AV:L/AC:L/PR:N/UI:R/C:L/I:H/A:L). The HP security bulletin HPSBPI04151 bundles this issue with other externally reported HPLIP flaws that could lead to remote code execution, privilege escalation, denial of service, or information disclosure, but the exact vulnerable component is not disclosed. No public exploit code or CISA KEV entry is identified at time of analysis, and the local vector plus mandatory user interaction prevents triggering without a user processing attacker-supplied input.
Local attackers with valid credentials on Linux systems running HPLIP can exploit symbolic-link handling flaws (CWE-61) in HPLIP components to read or modify arbitrary files, as described in HP security bulletin HPSBPI04151. This CVE is one of multiple issues remediated by HP in HPLIP and is assessed as a moderate, locally-scoped issue (CVSS 3.1: AV:L/AC:L/PR:L/UI:N, limited confidentiality/integrity impact) rather than an urgent priority, despite the broader impact list in the description; no public exploit code or CISA KEV active exploitation has been identified at time of analysis. Exploitation requires local access and a vulnerable HPLIP component that follows attacker-controllable symlinks at a predictable path, limiting impact to unauthorized file read/modification.
Insufficient origin validation in the Mattermost Desktop App (versions up to and including 6.2.2.0) lets server-rendered content from an untrusted or compromised Mattermost server reach local or private network resources, giving the attacker a limited information-disclosure window. Exploitation is not remote-only: the victim must be running the desktop client and actively connect to and view content from an attacker-controlled server (CVSS 4.7, AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N), and only confidentiality is affected - there is no integrity or availability impact. Mattermost credits game0v3r under its responsible disclosure policy (MMSA-2026-00698); there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, so overall risk is moderate and low priority.
Deactivated, deleted, or password-reset-locked Concrete CMS accounts keep working API access via any bearer token issued to them before the account state change, letting the holder continue calling the OAuth REST API endpoints under /ccm/api/1.0/* until that already-issued token expires on its own. All Concrete CMS versions before 9.5.4 are affected when the OAuth REST API is enabled; the vendor rates this only 2.0 (CVSS v4.0) and our independent assessment aligns with a low-impact, high-complexity authenticated issue, with no public exploit identified at time of analysis. The flaw is time-limited to the residual lifetime of the token and grants no more access than that token originally had, so it is a stale-credential/session-expiration problem rather than a route to new privileges.
A link-following (symlink) defect in the Dell Update Package (DUP) Framework before version 26.07.03 allows a locally authenticated high-privileged attacker to plant or control a symbolic link so that a privileged DUP file operation resolves to an attacker-chosen path, producing limited integrity and availability impact on the affected host. Exploitation is tightly constrained: the attack vector is local-only (CVSS:3.1/AV:L), requires high privileges (PR:H) plus the ability to create or control symlinks in a path consumed by a DUP operation, and depends on a race or predictable-path condition (AC:H), yielding a base score of 3.0 with I:L/A:L and C:N. No public exploit code was identified at time of analysis and there is no KEV confirmation of active exploitation; Dell has published a fixed version (26.07.03) via advisory DSA-2026-417. Note that the accompanying 'Information Disclosure' tag is not supported by the assessed vector, which shows no confidentiality impact, making this a low-priority local hardening issue rather than a data-exposure event.
Improper link resolution in the Dell Update Package (DUP) Framework before 26.07.03 allows an attacker who already holds high local privileges on a host to point framework file operations at a location of their choosing, resulting in unauthorized filesystem access with limited integrity and availability impact (CVSS 3.1 base score 3.0, AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L). Because exploitation demands pre-existing high privilege, local access, the ability to plant a symbolic link in a path the framework touches, and a successful link-resolution race, this is a low-severity, hard-to-reach issue that cannot be triggered remotely or by an unprivileged user. There is no public exploit identified at time of analysis, no CISA KEV listing, and a vendor patch is available as version 26.07.03.
Cross-tenant TLS configuration leakage in flightctl (shipped as Red Hat Edge Manager 1 and embedded in Red Hat Advanced Cluster Management for Kubernetes 2) lets an authenticated organization user have their HTTPS git repository's TLS settings - potentially InsecureSkipVerify, a custom CA bundle, or their own mTLS client certificate - applied to another organization's concurrent git.Clone operations, because the device-render worker installs each per-repository tls.Config into go-git's process-global Protocols map. Exploitation requires a multi-tenant deployment that renders devices for several organizations concurrently from a shared goroutine pool and is inherently non-deterministic (AC:H) since the attacker cannot control which tenant's configuration wins; single-tenant or serialized-rendering deployments are not exposed. The vendor scores this 6.6 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N) while our independent assessment rates privileges as PR:L because defining an HTTPS git repository only needs a normal authenticated tenant/organization account; no public exploit code was identified at time of analysis, there is no CISA KEV listing, and no EPSS score was provided.
Information exposure affecting Dell ECS 3.8.1.0 through 3.8.1.7 and Dell ObjectScale prior to 4.4.0.0 arises from the platform's use of a broken or risky cryptographic algorithm (CWE-327). Exploitation is not remotely reachable: it requires an attacker who already holds local access to a storage node together with a high-privileged account (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N per our assessment; NVD scored the confidentiality impact as C:H under the same vector structure), so the dominant limiting factor is the privileged-local-access precondition rather than any technical barrier. There is no public exploit code identified at time of analysis and CISA SSVC rates Exploitation 'none' and Automatable 'no'; the practical risk is low, bounded by credential/algorithm hygiene on the appliance, and remediation is available via ObjectScale 4.4.0.0 and the fixed Dell ECS release cited in Dell advisory DSA-2026-393.
Unauthenticated information disclosure in Rallly before 4.15.0 allows remote attackers who possess a poll's urlId to retrieve the names and email addresses of scheduled-event invitees through the polls.get tRPC procedure, regardless of the poll's privacy settings. The urlId is embedded in the public invite links Rallly generates and shares, so no credentials, user interaction, or non-default configuration are needed; CVSS 3.1 rates this 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). There is no public exploit code identified and no indication of active exploitation at time of analysis, and the vendor has released a fix in version 4.15.0.
Information disclosure in Zope AccessControl (zopefoundation AccessControl) versions prior to 7.4 allows authenticated users who already hold through-the-web Python code-authoring privileges to break out of the restricted-execution sandbox and read objects that the security policy is supposed to hide. Reaching str.format or str.format_map through a str subclass bypasses AccessControl's policy-restricted getattr and getitem guards, so a crafted format string can recursively walk attributes and subscriptions to disclose objects reachable from the values available to the formatting call. The impact is confined to confidentiality (CVSS 6.8, C:H with no integrity or availability impact); Vendor-released patch: 7.4, and no public exploit identified at time of analysis.
OpenFGA releases prior to 1.18.1 can have their ListUsers API return a user who should have been excluded by the authorization model, causing applications that use ListUsers to enumerate or enforce access to treat an excluded subject as authorized. The flaw is triggered only by a specific combination: a relation expressed as an intersection containing an exclusion operand (for example 'viewer: (org_member but not banned) and active'), where the included base is granted through a type-bound public wildcard ('user:*') and the excluded user also holds a concrete tuple satisfying another intersection operand. It is remotely reachable (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.3) but limited to callers already authorized to invoke ListUsers, and it does not affect the Check API in the vendor's reproducing tests; no public exploit code or CISA KEV listing was identified at time of analysis, and the issue is fixed in 1.18.1.
OAuth flow hijacking in the Jenkins Bitbucket Server Integration Plugin 6.0.1 and earlier allows an attacker to substitute the callback URL used in the plugin's OAuth authorization step and capture the Bitbucket access token issued to a victim. Exploitation is not against a static endpoint: the plugin must be installed with its OAuth authorization flow in active use, the attacker must have an OAuth handshake in progress, and a victim who is already authenticated must complete the authorization step (UI:R) within a timing window the attacker must hit (AC:H). Rated only CVSS 4.2 with no confidentiality or integrity impact beyond the scope of the hijacked victim's token, this is a genuine authentication-flow flaw but a low-priority one; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Credential isolation bypass in Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier allows an authenticated user who holds Item/Configure permission on a folder to reach 'alternative GitLab API token credentials' that are scoped to a different folder and that they are not entitled to use, because the plugin caches the GitLab API client under a cache key derived solely from the credentials ID and never incorporates the folder in which the credentials were resolved. Rated CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) under CWE-522 (insufficiently protected credentials), the issue is a moderate authorization/credential-isolation flaw rather than an unauthenticated remote compromise, and it only exists on multi-tenant Jenkins controllers that actually rely on folder-scoped credentials - single-tenant installations and controllers where all credentials are global/system-scoped see no practical impact. There is no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and the CVE is not KEV-listed, so it warrants scheduled patching rather than emergency response.
Information disclosure in Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier lets an authenticated Jenkins user who can influence the build log of a Gradle job trick the plugin into fetching build scan data from an attacker-controlled URL in preference to the Develocity server URL set in the plugin's global configuration. Because the plugin attaches the globally configured Develocity access key to that outbound request, the attacker can capture the credential; instances with no Develocity access key configured have nothing to leak, so exposure is conditional rather than universal. No public exploit code has been identified at time of analysis, and this is a genuine but moderate-severity issue: exploitation requires authenticated job-run or job-configure privileges plus a configured access key, and the resulting impact is limited to confidentiality (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
An out-of-bounds read in the userspace SMB daemon of MikroTik RouterOS before 7.24 allows unauthenticated remote attackers to read memory beyond the end of the request buffer by sending a minimal SMB1 SessionSetupAndX frame with a crafted uniPwdLen field value. The over-read occurs in the SessionSetupAndX handler before any credential validation, so no authentication or user interaction is required, though exploitation is only possible when the non-default SMB service is enabled and reachable on the network. Vendor-released patch: RouterOS 7.24; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the independent assessment rates the impact as limited memory disclosure (VC:L) with possible service disruption (VA:L) rather than code execution or full memory disclosure.
Origin validation errors in the AG-UI TypeScript client SDK (ag-ui 1.0) allow remote, low-privileged attackers who can influence an agent event stream to bypass event-origin checks and release the pending-interrupt gate, yielding low confidentiality, integrity, and availability impact. Affected deployments are those consuming untrusted or compromised AG-UI event sources; the advisory describes manipulation of the TEXT_MESSAGE_START argument, while the upstream fix PR #2701 also addresses an interrupt/resume state flaw where a stream emits an interrupt outcome and then finishes a subsequent run without a resume. Independent assessment rates this medium severity (vendor CVSS 4.0 base 5.3) with no signals of elevated real-world risk; no public exploit identified at time of analysis, and no CISA KEV entry.
A permissive cross-origin resource sharing (CORS) misconfiguration in the AG-UI aws-strands Python integration (ag-ui 0.3.0) allows a remote, unauthenticated attacker who convinces a victim to load an attacker-controlled web page to issue cross-origin requests against a deployed agent endpoint and read limited response data. The flaw is confined to deployments that bootstrap a FastAPI app via create_strands_app in integrations/aws-strands/python/src/ag_ui_strands/utils.py, where the helper installs wildcard CORS (any origin, method, and header) and mounts the agent route with no authentication dependency; deployments that supply an explicit origins allowlist, set cors_enabled=False, or attach an auth dependency are not affected. Exploitation is rated high complexity and difficult (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N, CVSS 4.0 base 2.3), the impact is limited to low confidentiality loss with no integrity or availability effect, and the browser prohibition on combining wildcard origins with credentialed requests further constrains what a successful attack can expose. No confirmed active exploitation (no CISA KEV listing) and no public exploit code were identified at time of analysis, and no EPSS score was provided in the source data.
Information disclosure in the a2ui agent-to-UI rendering library (versions 0.8, 0.9, and 1.0) lets a caller that can drive an A2UI surface read JavaScript prototype-chain members - such as __proto__, constructor, toString, and valueOf - through the Model Processor's data-binding path resolver, leaking internal object structure rather than application data. The flaw is an unauthenticated-of-the-network-but-role-limited (CVSS PR:L) defect in model-processor.ts, where path segments are evaluated as current[segment] without an own-property check; impact is limited to low confidentiality loss with no integrity or availability effect, and there is no public exploit identified at time of analysis. Vendor risk is low-to-moderate: a fix exists upstream as commit 1b3bff23 (PR #2355), but no tagged patched release has been independently confirmed.
In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: <TASK> delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)
In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.
In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.
In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().
In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]
In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: handle region split failure in apply_min_nr_regions() damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.
In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.
In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: return early from a zero-length flush SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path.
In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device.
In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix job completion fence cleanup ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. [robh: also fix goto]
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.
In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.
In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()
In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.
In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: clamp quantum and initial_quantum in change path The fq change path accepts TCA_FQ_QUANTUM in [1, INT_MAX] and TCA_FQ_INITIAL_QUANTUM up to INT_MAX, while fq_init() already clamps to [1, 1<<20]. A user can override the init clamp via tc qdisc change, restoring the small-quantum deficit spin that the init clamp prevents. Narrow iq_range.max to 1<<20 so TCA_FQ_INITIAL_QUANTUM is rejected at parse time. Clamp TCA_FQ_QUANTUM to [256, 1<<20] in fq_change() and fq_init() quantum to [256, 1<<20] for tiny-MTU devices. Conditions to recreate the bug: CONFIG_NET_SCH_FQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq tc qdisc change dev dummy0 root fq quantum 1 stab data 32768 size_log 15 cell_log 0
Cleartext exposure of origin credentials in AsyncHttpClient (AHC) 2.0.0-2.16.0 and 3.0.0-3.0.11 occurs when a Java application reaches an HTTPS origin through an HTTP CONNECT proxy while using preemptive origin authentication: the library attaches the origin's Authorization header - Basic or Digest credentials, plus per-connection NTLM/Kerberos/SPNEGO tokens - to the plaintext CONNECT request before any TLS tunnel exists, so the proxy and any observer on the client-to-proxy hop can read credentials meant only for the origin. The vulnerability is rated CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but a high attack-complexity qualifier, because exploitation requires the specific non-default combination of a CONNECT proxy, preemptive origin authentication, and an adversary positioned on that network segment; authentication requirements are not confirmed from the supplied vector beyond PR:N, and there is no public exploit identified at time of analysis. Vendor-released patches are 2.16.1 and 3.0.12, and because 3.0.12 is itself affected by a separate Digest-to-Basic downgrade flaw (GHSA-rqf5-2wxv-rjf4), 3.0.13 is the recommended target on the 3.x line.
Credential disclosure in AsyncHttpClient (Java) allows a client configured with a client-wide Realm via config.setRealm(...) and with redirect following enabled to leak Basic, Digest, Negotiate, or NTLM credentials to an attacker-controlled origin. When a cross-origin or scheme-downgrade redirect clears the per-exchange realm, the authentication interceptor in Interceptors.java falls back to config.getRealm() and re-attaches the client-wide credentials; if the attacker's target then answers HTTP 401, the client sends those credentials or tokens to that foreign origin. Affected releases are 2.14.5 through 2.16.0 and 3.0.9 through 3.0.11, fixed in 2.16.1 and 3.0.12; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the flaw is conditional on the specific client-wide Realm configuration, redirect following, attacker-influenced redirect, and a 401 response (AC:H per the assessed vector).
MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9 can be tricked into transmitting a locally selected file to a rogue or man-in-the-middle database server even when the allowLocalInfile option is explicitly set to false, because the connector processes a server-initiated LOCAL INFILE packet (0xfb) without honoring that setting. The exposure is narrow: the attacker can only receive the exact file the application already chose to load via a LOAD DATA LOCAL INFILE COM_QUERY, cannot redirect the request to an arbitrary path, and gains nothing unless the application organically loads sensitive data over an untrusted connection - so this is a low-severity (CVSS 3.7), highly conditional information-disclosure issue rather than a widespread threat. The vulnerability is unauthenticated at the network layer per the vector (PR:N) but requires high attack complexity (AC:H) and control of the server or the connection path; no public exploit code has been identified at time of analysis, and the flaw is fixed in the four versions listed above.
Information disclosure in Steeltoe's Management Endpoint actuator (Steeltoe.Management.Endpoint) prior to 4.3.0 allows an unauthenticated remote attacker who can reach the exposed /actuator/httpexchanges endpoint to harvest secrets that were previously captured in recorded request query strings - OAuth and password-reset tokens, API keys, and signed-URL signatures - because MaskedUri only redacts URI user-info and never inspects the query string. The same recorded URIs are written by the Steeltoe.Management.Endpoint.Actuators.HttpExchanges DEBUG logger, giving anyone with log access a second disclosure channel. Exploitation is config-gated (IncludeQueryString must be enabled, the endpoint must be explicitly exposed, and prior traffic must actually have carried query-string secrets), scoring CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N); no public exploit identified at time of analysis, and the issue is remediated in Steeltoe 4.3.0.
Mattermost Desktop App versions up to and including 6.2.2.0 fail to validate the URL scheme when deciding whether a link points to an internal server resource, so a network-positioned attacker who can intercept and downgrade the connection can make the client open a plugin popout window over an insecure (non-TLS) connection. Exploitation is narrow: it requires a man-in-the-middle position capable of forcing the scheme downgrade, an authenticated user of the affected client (PR:L per the CVSS vector), and that user clicking a crafted internal link (UI:R), which is why the vendor and independent scoring both land in the low range (vendor 2.6; independently assessed AV:A/AC:H). There is no indication of active exploitation and no public exploit code identified at time of analysis; the realistic impact is limited to integrity of the content rendered in the popout window, with no confidentiality or availability effect.
Dell SmartFabric Manager installations running versions earlier than 2.2.1 can disclose limited information to a low-privileged attacker who already holds a valid account and can either reach the management interface over the network or induce a legitimate user to perform an action. The flaw is rated CVSS 3.1 3.5 (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N), so it requires authentication plus user interaction and results only in low confidentiality impact with no integrity or availability effect - not an unauthenticated, default-configuration remote compromise. There is no evidence of active exploitation (the issue is not in CISA KEV), no public proof-of-concept identified at time of analysis, and no independent EPSS signal was supplied; this is a genuinely low-priority issue by every available signal.
Unauthenticated server-side request forgery in Nuxt OG Image (the npm package nuxt-og-image) 6.0.2 through 6.6.x allows any remote attacker who can reach a deployed Nuxt site to make the server issue arbitrary outbound GET requests by supplying a crafted fonts[].path value to the public /_og/d/** image-generation route. Exploitation works against the module's documented defaults (security.strict = false, security.secret = "", restrictRuntimeImagesToOrigin = false), and the response is blind: the outer HTTP status is 500 when the internal target answers with 2xx and 200 when it fails, giving a usable oracle to enumerate live loopback, RFC1918, link-local and cloud-metadata services, while slow targets can also tie up OG image render workers for the configured fetch/render timeouts. No public exploit identified at time of analysis (no KEV listing); vendor-released patch: 6.7.0.
Improper TLS certificate validation in Dell OpenManage Server Administrator (OMSA) managed-node builds prior to 11.1.0.3 allows an unauthenticated attacker who already occupies an adjacent-network position (same LAN or management VLAN) to man-in-the-middle OMSA traffic and accept a forged or invalid server certificate, resulting in disclosure and tampering of management data. The CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, score 6.8) confirms adjacent access and high attack complexity are required but no credentials or user interaction are needed once a MITM foothold exists; the issue is limited to the local management plane and cannot be triggered from the public internet. No public exploit code has been identified and the flaw is not in CISA KEV, so this is a moderate-real-risk hardening issue rather than an emergency, with the primary fix being the vendor release 11.1.0.3.
Unauthenticated attackers can retrieve hidden catalog entities from Vendure's publicly accessible Shop API by setting the filterOperator argument to OR, which causes the mandatory visibility guard to be OR-combined with the caller's own filters instead of AND-combined. The flaw affects the npm package @vendure/core in all versions from 1.0.0 up to (but not including) 3.6.5 and exposes disabled products and private collections or facets through the products, collections, and facets list queries. CVSS 3.1 is 5.3 (Medium, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), consistent with read-only information disclosure; no public exploit identified at time of analysis, although the upstream fix commit and its regression tests are publicly visible.
Chunked-transfer request smuggling in Sanic allows a remote unauthenticated attacker to plant a hidden second HTTP request inside the trailer-part of a chunked request, which Sanic then parses and routes as a genuine backend request on the same keep-alive connection. Affected versions are all releases before 24.12.1 and the 25.12.0 release (fixed in 24.12.1 and 25.12.1); the defect triggers on default configuration, with CVSS 3.1 scoring 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L) reflecting a request-boundary integrity failure rather than direct data compromise. A verified proof-of-concept is included in the upstream advisory showing a single TCP payload yielding two responses (a 405 for the outer POST and a 200 for a smuggled GET), meaning publicly available exploit code exists; the practical risk is highest when Sanic sits behind a reverse proxy, CDN, or load balancer that disagrees with Sanic on request boundaries.
Untrusted JavaScript running inside a vm2 sandbox before version 3.11.2 can reach the host-side internal state object via globalThis['VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL'], disclosing sandbox internals that were supposed to be invisible to guest code in the npm package vm2. The issue is a re-bypass of the earlier advisory GHSA-wp5r-2gw5-m7q7, and a short working proof-of-concept is published in the vendor advisory GHSA-2cm2-m3w5-gp2f, so publicly available exploit code exists; no CISA KEV listing appears in the supplied intelligence and no EPSS value was provided. The CVSS 4.0 base score is 6.9 with a confidentiality-only impact (VC:L, VI:N, VA:N, SC:N, PR:N, UI:N), consistent with the independent assessment that this is a genuine but low-severity information disclosure with no demonstrated code execution, integrity, or availability effect; the unauthenticated PR:N rating reflects the vector, while in practice the attacker must already be able to execute code inside the vm2 trust boundary (an application that embeds vm2 and runs attacker-controlled scripts).
Absolute host filesystem path disclosure in vm2 3.11.0 through 3.11.6 allows attacker-supplied JavaScript running inside a vm2 sandbox to force the host-realm source transformer to throw a SyntaxError (for example via eval with malformed source) and then read the resulting error's .stack property, which the bridge forwards to the host-realm formatter. Default new VM() and new NodeVM() configurations are affected with no special options, and the leak persists even when string eval is disabled, because the host-side transformer throws before eval is handled. Only information disclosure results - absolute paths from vm2, Node.js internals, and the embedding application's source tree plus host function names - with no write, no code execution, and no public exploit identified at time of analysis; the CVSS 4.0 score of 6.9 reflects the scope change and low confidentiality impact rather than a high-severity outcome.
Information disclosure in vm2 through version 3.11.7 allows sandboxed Node.js code to read the host process's call stack metadata: NodeVM exposes the host util module as an unfiltered shallow copy and also exposes the deprecated sys alias, and on Node.js 22.9 or later this hands sandbox code util.getCallSites(), which returns absolute file paths, function names, and line numbers for vm2 bridge internals and the embedding application's entrypoint. Remote attackers are unauthenticated (CVSS PR:N), but exploitation requires the host application to actually execute attacker-controlled JavaScript inside NodeVM and to be running Node.js >= 22.9; the leak is read-only and grants no code execution or write access. Vendor-released patch: vm2 3.11.8. No confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis.
The audit-log add-on in AshAuthentication stores pseudonymised client IP addresses using an unkeyed SHA-256 over a salt concatenated with the IP, truncated to 16 hex characters, so anyone who can already read the audit store can reverse those values back to the original addresses. Exploitation requires two explicit prerequisites: ip_privacy_mode must be set to :hash (the DSL default is :none, so this is an opt-in), and the attacker must already hold read access to the audit log via a database dump, backup, replica, or reader account. Reversal is trivial when the salt is left at the library's published fallback constant 'default-salt-change-in-production', which is used silently with no warning; even a properly configured salt only reduces the problem to 'that salt must leak', after which exhaustive enumeration over the 2^32 IPv4 space is cheap. Per the authoritative assessment this is a low-priority information-disclosure issue (assessed CVSS 3.1 1.8, CWE-760) affecting only client IP addresses with no integrity or availability impact; no public exploit identified at time of analysis, and vendor-released patches exist in 4.15.0 and 5.0.0-rc.14.
The audit_log add-on in the Elixir library AshAuthentication (ash_authentication) writes the full actor record into each audit entry's extra_data field, so the user's hashed_password digest is stored alongside the audit trail in versions from 4.12.0 up to but not including 4.15.0, and from 5.0.0-rc.0 up to but not including 5.0.0-rc.2. There is no network-facing or attacker-triggered disclosure path: entries accumulate from ordinary authenticated activity controlled by benign code, and an attacker's own requests only deposit the attacker's own digest, so exploitation requires that the attacker already hold independent read access to the audit store (database credentials, an audit role, a backup, or a log shipper). The result is exposure of password hashes that support offline cracking of every active account whose actions were audited; the vector is local, high complexity, and privileged (per the assessment PR:H), making this a log-hygiene/defense-in-depth issue rather than an actively exploited one - no public exploit code or CISA KEV entry has been identified at time of analysis, and vendor patches are available.
Server-side request forgery in the MISP sachertortephp library (a fork of CakePHP) lets any code that calls Xml::build() with the readFile option set to false still trigger an outbound HTTPS fetch whenever the supplied input string starts with 'https://', because a missing pair of parentheses in the gating condition makes the https:// branch independent of the readFile flag. The application then parses the remote response as XML and may hand it back to the caller, exposing internal-only services or attacker-chosen external endpoints to data disclosure, with the bundled HttpSocket configuration following up to 10 redirects to widen reachable targets. Exploitation is authenticated in practice (CVSS:4.0 PR:L / assessed CVSS:3.1 PR:L) and requires a reachable host-application code path that passes attacker-influenceable data to Xml::build(); no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV). The http:// branch is correctly gated and is not exploitable - only the https:// scheme bypasses the intended suppression of remote reads.
Password cracking in admin3 3.0.0 and earlier allows anyone who obtains the application's credential database to recover user plaintext passwords offline, because stored credentials use single-round MD5 salted only with the username and no key-derivation function. The flaw does not grant database access by itself - it requires a prior compromise (database breach, SQL injection, exposed backup, or insider/privileged access, reflected by the CVSS PR:H prerequisite), but once that precondition is met, cracking is trivial on commodity hardware; publicly available exploit code exists. With a vendor score of 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) and no confirmed active exploitation, this is a genuine but conditional, low-to-moderate risk that amplifies the impact of an upstream data exposure rather than creating one.
Disabling or locking a user account in admin3 through 3.0.0 does not invalidate that user's existing bearer tokens, so a previously authenticated user retains full access with their original permissions after the account is disabled. The root cause is twofold: the AuthInterceptor never re-checks the user's locked status on subsequent requests, and LocalSessionManager resets session expiry on every request, so a pre-existing token never lapses through inactivity. Publicly available exploit code exists (a proof-of-concept account-lockout-bypass script), and exploitation requires that the attacker already held a valid token issued while their account was enabled (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, CVSS 5.4) - a rogue-insider or post-disable persistence scenario rather than unauthenticated compromise. Confirmed actively exploited (CISA KEV) status is not indicated by the available data, and there is no privilege escalation beyond the disabled account's original permission set.
Information disclosure in Dell OpenManage Server Administrator (OMSA) managed nodes running versions prior to 11.1.0.3 stems from use of a broken or risky cryptographic algorithm in the product's network communication, which an unauthenticated remote attacker could leverage to expose limited information (CVSS 3.1: 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N). The high attack-complexity metric indicates that realistic exploitation requires a privileged man-in-the-middle position on the path to the managed node or offline cryptanalysis of captured management traffic, not a single direct request, and there is no integrity or availability impact. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, consistent with the independent assessment that this is a genuinely low-priority exposure typically confined to internal or out-of-band management networks. Affected platforms include the Windows managed-node patch and managed-node builds for RHEL 8.10, RHEL 9.4, SLES 15, and Ubuntu 22.04.
Acer System Monitoring, the WebSocket-enabled helper bundled with NitroSense and PredatorSense on Acer Nitro and Predator laptops, is configured to bind its listener to all network interfaces rather than to localhost, so any host that can reach the port on the same network segment can talk to the service without authentication or user interaction. The consequences are limited - the assessed impact is confined to low-level confidentiality, integrity and availability effects (minor telemetry exposure or restricted interaction with the service) - and the issue is compounded only mildly by the fact that the utility must actually be installed and running on a reachable machine. This is a low-priority finding: no public exploit code exists, no confirmed active exploitation has been reported, and the vendor vector (CVSS 4.0 score 2.7) plus an independent assessment (CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) agree that practical exposure is realistically limited to an attacker on the same LAN, hotel or office Wi-Fi.
Authenticated WordPress users holding the Author role or above can export every comment stored on a site running the Comments Import & Export plugin before version 2.5.4, because the export routine performs no moderate_comments capability check and does not scope results to the caller's own content. Exposed data includes commenter email addresses, IP addresses, unapproved comment bodies and comment meta. Publicly available exploit code exists, but the weakness is gated behind a valid Author-level credential, so exposure is concentrated on multi-author sites or installations that permit author-level self-registration; the impact is confidentiality-only and bounded.
Forged email tracking links in the Newsletter WordPress plugin before 9.3.8 let an unauthenticated attacker who first recovers the plugin's weakly generated signing key offline obtain any subscriber's session token and then read or modify that subscriber's stored personal data. The root cause is a signing key generated with insufficient entropy combined with tracking links signed by an unkeyed hash, which makes offline key recovery practical rather than dependent on a leaked secret; publicly available exploit code exists. Rated CVSS 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N), the issue is real but moderate: exploitation requires the tracking feature to be in use and a successful offline key-recovery step, and the impact per forged link is bounded to a single subscriber with no code execution or availability loss.
Information disclosure in the LearnPress WordPress plugin before 4.4.7 allows unauthenticated remote attackers to retrieve the correct answer for every option of a quiz question, along with the instructor's accompanying explanation, from any course configured to be taken without enrolling. Exploitation is remote and requires no authentication, no user interaction and no special client, but it is gated by a non-default course setting (enrollment-free access), which is why the vendor and our assessment rate the attack complexity as high and the overall CVSS at 3.7. Publicly available exploit code exists (WPScan published the vulnerability write-up), though there is no indication of confirmed active exploitation in CISA KEV; the practical harm is limited to quiz answer-key and explanation disclosure, with no credential, PII or write-access impact.
Double decoding in the Canva Desktop deeplink handler (versions before 1.125.0) lets an unauthenticated attacker who convinces a user to open a crafted custom-URI deeplink cause the application to load arbitrary same-origin content within that user's session. The flaw (CWE-174) yields limited integrity impact only, with no confidentiality or availability effect, and exploitation requires user interaction (UI:R). No public exploit code or confirmed active exploitation has been identified at time of analysis (no CISA KEV entry; no EPSS score supplied), and the vendor has released a fix in v1.125.0.
Unauthenticated attackers can write to the WordPress database option ai1wm_auth_header in All-in-One WP Migration and Backup versions up to 7.110 by sending a crafted Authorization: Basic header to admin-ajax.php or admin-post.php, because the plugin's Ai1wm_Main_Controller::init() method on the admin_init hook reads PHP_AUTH_USER and PHP_AUTH_PW without authentication or nonce checks and stores them as reversible base64. This integrity-only issue (CVSS 5.3) allows overwriting the stored credential with attacker-chosen values, and in environments using WordPress Application Passwords, legitimate credentials sent to /wp-admin/ are silently captured into the database, though extracting them requires separate read access. No public exploit code or active exploitation has been identified at time of analysis.
Risk cannot be meaningfully assessed for CVE-2026-82374 because the published record contains no description, no CVSS score or vector, no CWE classification, no CPE data, and no reference set; the sole available signal is that the record was reported by the vendor Ubuntu. With no affected package, version range, deployment mode, or attack vector specified, it is not possible to state who is affected or what an attacker could achieve, and no public exploit identified at time of analysis. The CVE is not associated with CISA KEV status or an EPSS score in the supplied intelligence, so no conclusion about active exploitation or likelihood can be drawn.
An unspecified defect in an as-yet-unidentified Ubuntu package is tracked as CVE-2026-82373, but the record carries no description, no CVSS vector, no CWE classification, and no patch reference, so the affected component, attack surface, and impact cannot be established. The only confirmed signal is provenance: the entry was reported by the Ubuntu security team through its vendor CVE tracker. No public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation, so risk cannot be meaningfully assessed from the provided data.
Local privilege escalation in the NetworkManager iodine VPN plugin (network-manager-iodine) lets an authenticated local user obtain code execution as root through option confusion in the root-privileged nm-iodine-service. A user who is permitted (typically via polkit for an active session) to create or edit an iodine VPN connection can supply a connection property value that iodine's command-line parser interprets as an option flag instead of data, producing behaviour that runs while the service is still root and before iodine drops privileges to an unprivileged user. Exploitation requires local access plus an installed, configured plugin, and no public exploit was identified at time of analysis; the assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (high confidentiality, integrity and availability impact, scope unchanged). Note that no CVSS vector, CWE, EPSS, KEV, SSVC or POC signal was supplied in the source data, so severity here derives from the independent assessment rather than vendor scoring.
Local privilege escalation in the NetworkManager VPNC plugin (network-manager-vpnc) lets a user who can create or modify a VPN connection profile inject newline/control characters into the generated vpnc configuration, causing a rogue directive such as 'Password helper' to be written and subsequently executed by the privileged helper when the connection is activated. The record is explicitly identified as an incomplete fix of CVE-2018-10900, meaning the original newline-injection vector was not fully neutralized, and exposure is limited to Linux hosts where the optional VPNC plugin is installed and the attacker already holds local rights to edit VPN settings. The provided intelligence contains no CVSS score, CWE, EPSS estimate, KEV listing, or POC indicator, so no public exploit identified at time of analysis and the actual risk depends on local privilege boundaries rather than remote reachability.
Attacker-influenced connection profile data can be routed into pppd's root-context pty/shell invocation in the ppp package (reported by Ubuntu), potentially letting a local user obtain code execution with the privileges of the pppd process. Our independent assessment scores this CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - local access is required, a connection must be initiated, and the target must actually use pppd for PPP/DSL/dial-up/mobile-broadband/VPN links, so exploitability is limited by how niche PPP is on modern systems; exploitation is not passive against a default configuration. No CVSS score, no CVSS vector and no CWE were supplied with the vendor report, there is no vendor-released patch identified at time of analysis and no public exploit identified at time of analysis. The exact privilege level required is not confirmed from the input, though the assessed vector implies an authenticated local user (PR:L).
Squid proxy software is affected by CVE-2026-62846, an issue tracked under the vendor's SQUID-2026:9 advisory identifier and reported into this dataset by the Ubuntu security team. No CVSS score, CVSS vector, CWE classification, or free-text technical description was supplied with the record, and the independent assessment concludes that risk cannot be meaningfully scored from the available input; therefore the specific impact, attack vector, and authentication prerequisites of this CVE remain unconfirmed. There is no indication of confirmed active exploitation (no CISA KEV entry) and no public exploit code identified at time of analysis, though the absence of exploit signals here reflects missing intelligence rather than a positive finding of unreachability.
Squid caching proxy is affected by an uncharacterized security issue tracked as CVE-2026-61642 and referenced upstream only as '[SQUID-2026:6]', surfaced through Ubuntu's distributor advisory ingestion. The provided data contains no vulnerability description text, no CVSS score or vector, and no CWE, so the impact, attack vector, and required proxy deployment mode (forward or reverse) cannot be determined; no public exploit code identified at time of analysis. Because exploitation prerequisites are unconfirmed and risk cannot be meaningfully scored, defenders running Squid - particularly Ubuntu-packaged Squid - should retrieve the upstream SQUID-2026:6 advisory and the corresponding Ubuntu security notice to establish affected versions and exposure before treating this as actionable.
Sandbox bypass in the n8n Git node lets an authenticated member-level user read git repository objects located outside the path enforced by N8N_RESTRICT_FILE_ACCESS_TO. n8n validates a relative remote URL against the configured repositoryPath, but git is then executed with that directory as its working directory and walks up to the enclosing repository's top level, where it resolves the identical URL string from outside the sandbox; a subsequent fetch or pull merges the external repository's objects into the attacker's own repository, from which the contents can be read back. Versions before 1.123.76, 2.37.7, and 2.38.2 are affected; no public exploit code has been identified at time of analysis, and the confidentiality-only impact (CVSS 4.0 base 5.3, assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) is neutralized by upgrading or by disabling the Git node.
Credential leakage in the rmcp Rust SDK (the official Rust SDK for the Model Context Protocol) prior to 2.1.0 allows an attacker who controls or compromises an MCP endpoint to harvest API keys and tokens from victim clients. StreamableHttpClientTransport builds its default reqwest HTTP client with automatic redirect following and replays caller-supplied StreamableHttpClientTransportConfig.custom_headers on cross-origin 307/308 redirects without marking them sensitive, so secrets such as x-api-key headers are forwarded to the redirect target where the attacker can capture and reuse them. The issue is not actively exploited per available intelligence, no public exploit code was identified at time of analysis, and exploitation is condition-gated: it requires a client that (a) runs a pre-2.1.0 version, (b) places secrets in custom_headers rather than the standard Authorization path, and (c) talks to a malicious or compromised MCP server, which is why the assessed vector carries high attack complexity and limits impact to confidentiality (CVSS 6.8, AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N, CWE-200). A vendor patch is available in rmcp 2.1.0.
Cross-tenant data exposure on the djust live WebSocket path affects installations before 1.0.7 that use host-, subdomain-, or domain-based TenantResolvers for multi-tenancy. Because the request rebuilt by handle_mount and ViewRuntime._build_request carries no client Host, get_host() falls back to "testserver", so the tenant resolves to None on the live path even though the ordinary HTTP path resolves it correctly; with STRICT_MODE=False the tenant-scoped managers then return unscoped rows and an authenticated user can read other tenants' data. With the default STRICT_MODE the identical flaw only yields empty querysets (broken tenancy, no disclosure). No public exploit code exists and there is no confirmed active exploitation; EPSS/KEV data were not provided, and the CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N, 6.3) reflects the high attack complexity and the dependency on an explicit STRICT_MODE=False configuration.
Information disclosure in the djust Python WebSocket framework before 1.0.7 causes Django Model instances assigned to public (non-underscore) view attributes to be serialized to the browser with no sensitive-field denylist, exposing fields such as the password hash, is_staff/is_superuser privilege flags, tokens, and other PII inside the render payload sent to the client. Exploitation requires authenticated access to a view that assigns a full model to a public attribute (CVSS:3.1 AV:N/PR:L), and the resulting impact is confidentiality-only but rated High (C:H/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Prototype pollution in the unflatten helper of Builder.io Gen2 SDKs (the @builder.io/sdk-react, sdk-vue, sdk-svelte and sdk-solid packages at or below 5.2.11, and sdk-angular, sdk-react-nextjs and sdk-qwik at or below 0.25.13) lets unauthenticated remote attackers poison Object.prototype in a victim's browser by luring the victim into opening a crafted preview link whose builder.userAttributes query parameters carry __proto__ or prototype segments. Exploitation is not automatable against a passive server - it hinges on user interaction (UI:P), because the SDK must actually be running in the victim's browser when the malicious URL is processed, and real harm (DOM XSS, client-side logic tampering, denial of service) only materializes if downstream application code reads the polluted inherited properties. No CISA KEV entry and no public exploit code were identified at time of analysis, and the independent assessment rates real-world risk as moderate-to-low.
Remote, authenticated administrators of Cisco Identity Services Engine (ISE) can escalate from the web management interface to write access on the appliance's underlying operating system by sending a single crafted HTTP request, and Cisco confirms root is easy to reach from that primitive, making the practical outcome full device compromise. The flaw is improper restriction of resource/file names (CWE-641) in the ISE management web/API layer, reachable over the network with no user interaction but requiring valid administrative credentials (CVSS 3.1 PR:H), so it is a post-authentication escalation path rather than a pre-auth entry point. Cisco's published base score of 4.9 (Medium) understates the outcome - the vendor assigned a High Security Impact Rating for exactly this reason, and our independent assessment raises confidentiality, integrity and availability impact to High; no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV.
OpenTelemetry-Go versions 1.5.0 through 1.44.0 can write sensitive collector configuration into an application's own logs when the application explicitly opts into internal diagnostic logging through otel.SetLogger at Info verbosity: the TracerProvider created event serializes span processor, exporter, and client configuration, exposing OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. Anyone able to read those logs - local files, aggregated log stores, or a SIEM - can reconstruct internal collector topology and can recover credentials or tokens where operators embedded them in Zipkin URL user-info or query strings. The vendor CVSS 4.0 base score is 2.0 and no public exploit identified at time of analysis; note that OTLP authentication headers, TLS key material, and span payloads are never written by this path, and default OpenTelemetry configurations that do not install a logger are unaffected because the default logger does not emit the diagnostic event.
An out-of-bounds read in GPAC 26.08-DEV (the wait_for_header_and_parse routine in src/utils/downloader.c) can disclose memory contents or crash the process when the downloader parses a crafted or empty Content-Range value in an HTTP response header. The victim must actively initiate a download from a malicious or man-in-the-middle server for the malformed header to reach the parser; the vulnerable code path is in GPAC's generic HTTP/fetch machinery rather than a media-decoding path, and the consequence is limited to information disclosure or a crash - no write primitive or code execution is demonstrated. Publicly available exploit code exists (the issue is tracked publicly on the GPAC GitHub project) but the flaw is not confirmed actively exploited (CISA KEV), and the assessed impact is low on both the availability and confidentiality axes.
Information disclosure in the Tanium Discover module allows an authenticated console user to read data they should not have access to, with the vendor confirming the flaw has been addressed. The vulnerability requires network reachability and a valid low-privilege Tanium session (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) but no user interaction, and it affects only organizations that have licensed and deployed the optional Discover component. Impact is confined to confidentiality - there is no integrity or availability effect - and no public exploit code or confirmed active exploitation has been identified at time of analysis.
Clear-text logging in Arista EOS with the gRPC Network Packet Sampling Interface (gNPSI) enabled can expose gNPSI client credentials to authenticated users who can read local or remote accounting logs. Affected devices are those running EOS with the non-default, opt-in gNPSI feature configured; exploitation requires an already-authenticated user with log access and specific conditions under which the credentials are written in clear text. This is a moderate-severity information-disclosure issue (vendor CVSS 4.0 score 6.0), not remote code execution or unauthenticated access, and no public exploit has been identified at time of analysis.
Denial of service in HP's HPLIP (HP Linux Imaging and Printing Software) printing stack is reachable when a physically-present attacker supplies specially crafted input that triggers a CWE-191 integer underflow, crashing or hanging affected components; the scored CVSS:3.1 vector (AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) limits impact to availability only, with no confidentiality or integrity loss. The physical attack vector (direct hardware/USB or local physical access) is the dominant gating factor and rules out remote or network-based exploitation, and no public exploit has been identified at time of analysis. HP has stated that it identified and remediated the underlying issues, so a vendor fix is available per advisory hpsbpi04151, though the specific affected and fixed version ranges are not enumerated here and must be confirmed against that bulletin. Overall this is a genuine but low-priority issue: real availability impact, but exploitation requires an attacker to already have hands on the machine.
Cleartext disclosure of peer VRRP authentication credentials in Arista EOS log output allows an authenticated, privileged user - or anyone able to read a system receiving forwarded agent trace logs - to recover the shared secret that authenticates VRRP advertisements, without needing any presence on the VRRP network segment itself. The defect applies to EOS platforms configured with authenticated VRRP; exploitation requires high-privilege access to the switch's agent trace logs or to a downstream log collector, and the resulting impact is confidentiality-only (CVSS 4.0 base 2.1; our independent assessment rates it CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, i.e. PR:H and C:L). No public exploit code and no confirmed active exploitation were identified at time of analysis; this is a low-priority log-hygiene issue whose only notable edge over routine secret-in-log bugs is that the leak escapes the on-link boundary normally assumed for VRRP secrets.
Denial of service in HP Linux Imaging and Printing Software (HPLIP) can be triggered by a physically present attacker who supplies crafted input via a local device or print/scan job, exploiting improper array index validation (CWE-129). Although HP's advisory bundles several vulnerabilities that could potentially enable a broader range of impacts, the specific vector for this CVE limits the effect to availability (system crash or service disruption) with no confidentiality or integrity impact. No public exploit code or active exploitation has been identified at time of analysis, and the primary prerequisite is physical access to the target system.
Command injection (CWE-78) in HP's HPLIP (HP Linux Imaging and Printing) software enables an unauthenticated local user to execute commands or modify files with high integrity impact (VI:H) after active user interaction, matching HP's CVSS 4.0 score of 6.8 (AV:L/AC:L/PR:N/UI:A/VC:L/VI:H/VA:L) and the independent CVSS 3.1 assessment (AV:L/AC:L/PR:N/UI:R/C:L/I:H/A:L). The HP security bulletin HPSBPI04151 bundles this issue with other externally reported HPLIP flaws that could lead to remote code execution, privilege escalation, denial of service, or information disclosure, but the exact vulnerable component is not disclosed. No public exploit code or CISA KEV entry is identified at time of analysis, and the local vector plus mandatory user interaction prevents triggering without a user processing attacker-supplied input.
Local attackers with valid credentials on Linux systems running HPLIP can exploit symbolic-link handling flaws (CWE-61) in HPLIP components to read or modify arbitrary files, as described in HP security bulletin HPSBPI04151. This CVE is one of multiple issues remediated by HP in HPLIP and is assessed as a moderate, locally-scoped issue (CVSS 3.1: AV:L/AC:L/PR:L/UI:N, limited confidentiality/integrity impact) rather than an urgent priority, despite the broader impact list in the description; no public exploit code or CISA KEV active exploitation has been identified at time of analysis. Exploitation requires local access and a vulnerable HPLIP component that follows attacker-controllable symlinks at a predictable path, limiting impact to unauthorized file read/modification.
Insufficient origin validation in the Mattermost Desktop App (versions up to and including 6.2.2.0) lets server-rendered content from an untrusted or compromised Mattermost server reach local or private network resources, giving the attacker a limited information-disclosure window. Exploitation is not remote-only: the victim must be running the desktop client and actively connect to and view content from an attacker-controlled server (CVSS 4.7, AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N), and only confidentiality is affected - there is no integrity or availability impact. Mattermost credits game0v3r under its responsible disclosure policy (MMSA-2026-00698); there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, so overall risk is moderate and low priority.
Deactivated, deleted, or password-reset-locked Concrete CMS accounts keep working API access via any bearer token issued to them before the account state change, letting the holder continue calling the OAuth REST API endpoints under /ccm/api/1.0/* until that already-issued token expires on its own. All Concrete CMS versions before 9.5.4 are affected when the OAuth REST API is enabled; the vendor rates this only 2.0 (CVSS v4.0) and our independent assessment aligns with a low-impact, high-complexity authenticated issue, with no public exploit identified at time of analysis. The flaw is time-limited to the residual lifetime of the token and grants no more access than that token originally had, so it is a stale-credential/session-expiration problem rather than a route to new privileges.
A link-following (symlink) defect in the Dell Update Package (DUP) Framework before version 26.07.03 allows a locally authenticated high-privileged attacker to plant or control a symbolic link so that a privileged DUP file operation resolves to an attacker-chosen path, producing limited integrity and availability impact on the affected host. Exploitation is tightly constrained: the attack vector is local-only (CVSS:3.1/AV:L), requires high privileges (PR:H) plus the ability to create or control symlinks in a path consumed by a DUP operation, and depends on a race or predictable-path condition (AC:H), yielding a base score of 3.0 with I:L/A:L and C:N. No public exploit code was identified at time of analysis and there is no KEV confirmation of active exploitation; Dell has published a fixed version (26.07.03) via advisory DSA-2026-417. Note that the accompanying 'Information Disclosure' tag is not supported by the assessed vector, which shows no confidentiality impact, making this a low-priority local hardening issue rather than a data-exposure event.
Improper link resolution in the Dell Update Package (DUP) Framework before 26.07.03 allows an attacker who already holds high local privileges on a host to point framework file operations at a location of their choosing, resulting in unauthorized filesystem access with limited integrity and availability impact (CVSS 3.1 base score 3.0, AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L). Because exploitation demands pre-existing high privilege, local access, the ability to plant a symbolic link in a path the framework touches, and a successful link-resolution race, this is a low-severity, hard-to-reach issue that cannot be triggered remotely or by an unprivileged user. There is no public exploit identified at time of analysis, no CISA KEV listing, and a vendor patch is available as version 26.07.03.
Cross-tenant TLS configuration leakage in flightctl (shipped as Red Hat Edge Manager 1 and embedded in Red Hat Advanced Cluster Management for Kubernetes 2) lets an authenticated organization user have their HTTPS git repository's TLS settings - potentially InsecureSkipVerify, a custom CA bundle, or their own mTLS client certificate - applied to another organization's concurrent git.Clone operations, because the device-render worker installs each per-repository tls.Config into go-git's process-global Protocols map. Exploitation requires a multi-tenant deployment that renders devices for several organizations concurrently from a shared goroutine pool and is inherently non-deterministic (AC:H) since the attacker cannot control which tenant's configuration wins; single-tenant or serialized-rendering deployments are not exposed. The vendor scores this 6.6 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N) while our independent assessment rates privileges as PR:L because defining an HTTPS git repository only needs a normal authenticated tenant/organization account; no public exploit code was identified at time of analysis, there is no CISA KEV listing, and no EPSS score was provided.
Information exposure affecting Dell ECS 3.8.1.0 through 3.8.1.7 and Dell ObjectScale prior to 4.4.0.0 arises from the platform's use of a broken or risky cryptographic algorithm (CWE-327). Exploitation is not remotely reachable: it requires an attacker who already holds local access to a storage node together with a high-privileged account (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N per our assessment; NVD scored the confidentiality impact as C:H under the same vector structure), so the dominant limiting factor is the privileged-local-access precondition rather than any technical barrier. There is no public exploit code identified at time of analysis and CISA SSVC rates Exploitation 'none' and Automatable 'no'; the practical risk is low, bounded by credential/algorithm hygiene on the appliance, and remediation is available via ObjectScale 4.4.0.0 and the fixed Dell ECS release cited in Dell advisory DSA-2026-393.
Unauthenticated information disclosure in Rallly before 4.15.0 allows remote attackers who possess a poll's urlId to retrieve the names and email addresses of scheduled-event invitees through the polls.get tRPC procedure, regardless of the poll's privacy settings. The urlId is embedded in the public invite links Rallly generates and shares, so no credentials, user interaction, or non-default configuration are needed; CVSS 3.1 rates this 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). There is no public exploit code identified and no indication of active exploitation at time of analysis, and the vendor has released a fix in version 4.15.0.
Information disclosure in Zope AccessControl (zopefoundation AccessControl) versions prior to 7.4 allows authenticated users who already hold through-the-web Python code-authoring privileges to break out of the restricted-execution sandbox and read objects that the security policy is supposed to hide. Reaching str.format or str.format_map through a str subclass bypasses AccessControl's policy-restricted getattr and getitem guards, so a crafted format string can recursively walk attributes and subscriptions to disclose objects reachable from the values available to the formatting call. The impact is confined to confidentiality (CVSS 6.8, C:H with no integrity or availability impact); Vendor-released patch: 7.4, and no public exploit identified at time of analysis.
OpenFGA releases prior to 1.18.1 can have their ListUsers API return a user who should have been excluded by the authorization model, causing applications that use ListUsers to enumerate or enforce access to treat an excluded subject as authorized. The flaw is triggered only by a specific combination: a relation expressed as an intersection containing an exclusion operand (for example 'viewer: (org_member but not banned) and active'), where the included base is granted through a type-bound public wildcard ('user:*') and the excluded user also holds a concrete tuple satisfying another intersection operand. It is remotely reachable (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.3) but limited to callers already authorized to invoke ListUsers, and it does not affect the Check API in the vendor's reproducing tests; no public exploit code or CISA KEV listing was identified at time of analysis, and the issue is fixed in 1.18.1.
OAuth flow hijacking in the Jenkins Bitbucket Server Integration Plugin 6.0.1 and earlier allows an attacker to substitute the callback URL used in the plugin's OAuth authorization step and capture the Bitbucket access token issued to a victim. Exploitation is not against a static endpoint: the plugin must be installed with its OAuth authorization flow in active use, the attacker must have an OAuth handshake in progress, and a victim who is already authenticated must complete the authorization step (UI:R) within a timing window the attacker must hit (AC:H). Rated only CVSS 4.2 with no confidentiality or integrity impact beyond the scope of the hijacked victim's token, this is a genuine authentication-flow flaw but a low-priority one; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Credential isolation bypass in Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier allows an authenticated user who holds Item/Configure permission on a folder to reach 'alternative GitLab API token credentials' that are scoped to a different folder and that they are not entitled to use, because the plugin caches the GitLab API client under a cache key derived solely from the credentials ID and never incorporates the folder in which the credentials were resolved. Rated CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) under CWE-522 (insufficiently protected credentials), the issue is a moderate authorization/credential-isolation flaw rather than an unauthenticated remote compromise, and it only exists on multi-tenant Jenkins controllers that actually rely on folder-scoped credentials - single-tenant installations and controllers where all credentials are global/system-scoped see no practical impact. There is no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and the CVE is not KEV-listed, so it warrants scheduled patching rather than emergency response.
Information disclosure in Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier lets an authenticated Jenkins user who can influence the build log of a Gradle job trick the plugin into fetching build scan data from an attacker-controlled URL in preference to the Develocity server URL set in the plugin's global configuration. Because the plugin attaches the globally configured Develocity access key to that outbound request, the attacker can capture the credential; instances with no Develocity access key configured have nothing to leak, so exposure is conditional rather than universal. No public exploit code has been identified at time of analysis, and this is a genuine but moderate-severity issue: exploitation requires authenticated job-run or job-configure privileges plus a configured access key, and the resulting impact is limited to confidentiality (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
An out-of-bounds read in the userspace SMB daemon of MikroTik RouterOS before 7.24 allows unauthenticated remote attackers to read memory beyond the end of the request buffer by sending a minimal SMB1 SessionSetupAndX frame with a crafted uniPwdLen field value. The over-read occurs in the SessionSetupAndX handler before any credential validation, so no authentication or user interaction is required, though exploitation is only possible when the non-default SMB service is enabled and reachable on the network. Vendor-released patch: RouterOS 7.24; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the independent assessment rates the impact as limited memory disclosure (VC:L) with possible service disruption (VA:L) rather than code execution or full memory disclosure.
Origin validation errors in the AG-UI TypeScript client SDK (ag-ui 1.0) allow remote, low-privileged attackers who can influence an agent event stream to bypass event-origin checks and release the pending-interrupt gate, yielding low confidentiality, integrity, and availability impact. Affected deployments are those consuming untrusted or compromised AG-UI event sources; the advisory describes manipulation of the TEXT_MESSAGE_START argument, while the upstream fix PR #2701 also addresses an interrupt/resume state flaw where a stream emits an interrupt outcome and then finishes a subsequent run without a resume. Independent assessment rates this medium severity (vendor CVSS 4.0 base 5.3) with no signals of elevated real-world risk; no public exploit identified at time of analysis, and no CISA KEV entry.
A permissive cross-origin resource sharing (CORS) misconfiguration in the AG-UI aws-strands Python integration (ag-ui 0.3.0) allows a remote, unauthenticated attacker who convinces a victim to load an attacker-controlled web page to issue cross-origin requests against a deployed agent endpoint and read limited response data. The flaw is confined to deployments that bootstrap a FastAPI app via create_strands_app in integrations/aws-strands/python/src/ag_ui_strands/utils.py, where the helper installs wildcard CORS (any origin, method, and header) and mounts the agent route with no authentication dependency; deployments that supply an explicit origins allowlist, set cors_enabled=False, or attach an auth dependency are not affected. Exploitation is rated high complexity and difficult (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N, CVSS 4.0 base 2.3), the impact is limited to low confidentiality loss with no integrity or availability effect, and the browser prohibition on combining wildcard origins with credentialed requests further constrains what a successful attack can expose. No confirmed active exploitation (no CISA KEV listing) and no public exploit code were identified at time of analysis, and no EPSS score was provided in the source data.
Information disclosure in the a2ui agent-to-UI rendering library (versions 0.8, 0.9, and 1.0) lets a caller that can drive an A2UI surface read JavaScript prototype-chain members - such as __proto__, constructor, toString, and valueOf - through the Model Processor's data-binding path resolver, leaking internal object structure rather than application data. The flaw is an unauthenticated-of-the-network-but-role-limited (CVSS PR:L) defect in model-processor.ts, where path segments are evaluated as current[segment] without an own-property check; impact is limited to low confidentiality loss with no integrity or availability effect, and there is no public exploit identified at time of analysis. Vendor risk is low-to-moderate: a fix exists upstream as commit 1b3bff23 (PR #2355), but no tagged patched release has been independently confirmed.
In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: <TASK> delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)
In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.
In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.
In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().
In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]
In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: handle region split failure in apply_min_nr_regions() damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.
In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.
In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: return early from a zero-length flush SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path.
In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device.
In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix job completion fence cleanup ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. [robh: also fix goto]
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.
In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.
In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()
In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.
In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.