| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain deployment configurations, could have allowed an authenticated user to poison cached page content served to other users due to improper cache key construction. |
| In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series). |
| Payy is an Ethereum L2 zk-rollup for privacy preserving and regulatory compliant transactions. Prior to version 1.3.0, agg_agg forwards the compacted message stream from its inner proofs into a public messages: [Field; 1000] array, but it never checks that the unused tail of the outer array is zero. A registered prover can build a valid agg_final proof for an approved rollup block while inserting an extra burn message after the real messages. RollupV1.verifyRollup() then parses that public input as a normal burn and transfers USDC from the rollup contract to the attacker. This is a severe circuit soundness failure: the proof system accepts a public statement whose messages array is not fully derived from the verified inner proofs. On the current deployment, verifyRollup() is restricted to the existing allowlisted prover, so a fresh public caller cannot submit the invalid proof directly. That gate limits who can reach L1 today; it does not make the circuit statement sound. The issue becomes permissionless under the prover model described in the Payy whitepaper. Section 3.3.2 states: "To join as a prover, the prover is required to submit a small stake", and Section 3.3.1 states that if a prover fails to submit, "other nodes can submit the block proof instead." In that model, an attacker only needs to become a registered prover and use public validator approval data for an already approved block. This issue has been patched in version 1.3.0. |
| wlc is a Weblate command-line client using Weblate's REST API. Prior to 2.0.1, automatically discovered configuration from .weblate, .weblate.ini, or weblate.ini can select the API URL while an unscoped API token is supplied through WLC_KEY or --key without a matching WLC_URL or --url. When wlc runs in an untrusted repository, pull request checkout, or directory with untrusted ancestor configuration, it can send the token to an attacker-controlled project-configured URL. URL-scoped keys in [keys] are not affected. This issue is fixed in version 2.0.1. |
| The file write tool in Amazon Kiro IDE versions before 1.0.242 might allow remote unauthenticated actors to inject crafted instructions into the agent's context. When a user runs the agent in a crafted repository as an untrusted workspace, sending any message can cause agent modifications to auto-loaded global configuration paths.
We recommend you upgrade to Kiro IDE version 1.0.242 or later. Users who ran the agent in an untrusted workspace on an earlier version should also review the global Kiro configuration directory (~/.kiro) for entries they did not create. |
| A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database.
This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1. |
| For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945.
This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1. |
| Laci Synchroni is a decentralized mod and appearance sync server and plugin for Dalamud. Versions of the backend prior to 1.2.3 have an improper authentication vulnerability in the application's OAuth2 login flow. The application relies on client-side state by trusting the `UID` field inside the `Authentications` object of a user's local `config.json` file. By manually editing this local file on their PC prior to logging in, a user can supply an arbitrary UID. Because the server fails to validate that the authenticated OAuth2 identity matches the requested UID, an attacker can fully impersonate any target user and perform actions on their behalf. This issue has been resolved in version 1.2.3. The patch modifies `AuthorizeOauthAsync` inside the `SecretKeyAuthenticatorService` to strictly bind the lookup of the requested User ID (`requestedUid`) to the record of the successfully authenticated identity (`primaryUid`). The server will no longer load or return session tokens for a requested UID unless it matches the verified, authenticated database record. No known workarounds are available. |
| The WP Fastest Cache WordPress plugin before 1.5.1 does not include a set of tracking-related query parameters in its page-cache key while still caching pages requested with them, allowing unauthenticated attackers to have a page rendered under their own request context stored under, and served from, the clean URL's cache entry to every subsequent visitor. |
| Forwarding information received from a host listed as a trusted proxy is not kept separate from Dovecot's own authentication fields, so a value sent by that host can be injected as an internal authentication field. Any host permitted to act as a trusted proxy can authenticate as any user without knowing that user's password. This affects deployments whose password database honours a field that permits authentication without a password. Deployments that do not configure trusted proxies are not affected. Restrict the list of trusted proxy networks to hosts that are fully under your control. Update to non-vulnerable version. No publicly available exploits are known. |
| GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.1.7, 19.2 before 19.2.5, and 19.3 before 19.3.1 that, under certain conditions, an authenticated user with developer-role permissions could have influenced the execution environment of Pipeline Execution Policy enforcement jobs, due to improper handling of job dependencies. |
| django CMS is a content management system powered by Django. Prior to 5.0.8 and in 5.1.0a1, the django CMS page cache in cms/cache/page.py ignores request headers declared by plugins through get_vary_cache_on(). The _page_cache_key function includes the cache prefix, site, language, path, and timezone but not the declared header values. Although set_page_cache adds those names to the response Vary header, get_page_cache retrieves the first stored variant under the same header-agnostic key. When CMS_PAGE_CACHE is enabled and a plugin varies content on a header such as Country-Code, one visitor can receive another visitor’s request-specific content, and an unauthenticated attacker can prime the cache with attacker-chosen content. This issue is fixed in versions 5.0.8 and 5.1.0. |
| In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread. |
| pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can install configDependencies declared in pnpm-workspace.yaml before command dispatch. Before the patch, a repository could declare pacquet or @pnpm/pacquet as a config dependency and pnpm treated that repository-controlled dependency as an install-engine opt-in. During install, pnpm resolved a platform-specific @pacquet/<platform>-<arch>/pacquet binary from node_modules/.pnpm-config/<packageName> and spawned it as the developer or CI user. This vulnerability is fixed in 10.34.2 and 11.5.3. |
| Dell Wyse Management Suite, versions prior to WMS 5.5 HF1, contain an Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Remote Code Execution. |
| A malicious authoritative server can send a crafted zone via the ZoneToCache function that leads to cache poisoning. |
| No cwe for this issue in Windows DHCP Server allows an unauthorized attacker to perform tampering over a network. |
| Nuxt is an open-source web development framework for Vue.js. In Nuxt versions 3.1.0 to before 3.21.6 and 4.0.0-alpha.1 to before 4.4.6 and @nuxt/nitro-server versions 3.20.0 to before 3.21.6 and 4.0.0-alpha.1 to before 4.4.6, the /__nuxt_island/* endpoint accepts attacker-controlled props query/body parameters and renders any island component without verifying that the URL-resident hash (<Name>_<hashId>.json) was actually issued for those inputs by <NuxtIsland>. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query. This issue has been patched in versions 3.21.6 and 4.4.6. |
| Insufficient validation of untrusted input in Chromoting in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| NLnet Labs Unbound up to and including version 1.25.0 is vulnerable to poisoning via promiscuous records for the authority section. Promiscuous RRSets that complement DNS replies in the authority section can be used to trick Unbound to cache such records. If an adversary is able to attach such records in a reply (i.e., spoofed packet, fragmentation attack) he would be able to poison Unbound's cache. A malicious actor can exploit the possible poisonous effect by injecting RRSets other than NS that are also accompanied by address records in a reply, for example MX. This could be achieved by trying to spoof a reply packet or fragmentation attacks. Unbound would then accept the relative address records in the additional section and cache them if the authority RRSet has enough trust at this point, i.e., in-zone data for the delegation point. Unbound 1.25.1 contains a patch with a fix that disregards address records from the additional section if they are not explicitly relevant only to authority NS records, mitigating the possible poison effect. This is a complement fix to CVE-2025-11411. |
