🚨 CVE-2026-25119
Gogs is an open source self-hosted Git service. Prior to 0.14.3, when ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled, Gogs accepts the configured authentication header (default: X-WEBAUTH-USER) directly from client requests without validating that the request originated from a trusted reverse proxy. Any remote attacker who can reach the Gogs service can forge this header to impersonate any user or trigger automatic account creation, completely bypassing authentication. This vulnerability is fixed in 0.14.3.
🎖@cveNotify
Gogs is an open source self-hosted Git service. Prior to 0.14.3, when ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled, Gogs accepts the configured authentication header (default: X-WEBAUTH-USER) directly from client requests without validating that the request originated from a trusted reverse proxy. Any remote attacker who can reach the Gogs service can forge this header to impersonate any user or trigger automatic account creation, completely bypassing authentication. This vulnerability is fixed in 0.14.3.
🎖@cveNotify
GitHub
auth: trust reverse proxy auth header only from configured proxies (#… · gogs/gogs@0089c4c
…8264)
🚨 CVE-2026-52798
Gogs is an open source self-hosted Git service. Prior to 0.14.3, although .ipynb previews are sanitized on the server side via /-/api/sanitize_ipynb, the inserted content is re-rendered on the client side without sanitization using marked() on elements with the .nb-markdown-cell class. During this process, links containing schemes such as javascript: can be regenerated. As a result, when a victim views an attacker-crafted .ipynb file and clicks the link, arbitrary JavaScript is executed in the Gogs origin, leading to a click-based Stored XSS. This vulnerability is fixed in 0.14.3.
🎖@cveNotify
Gogs is an open source self-hosted Git service. Prior to 0.14.3, although .ipynb previews are sanitized on the server side via /-/api/sanitize_ipynb, the inserted content is re-rendered on the client side without sanitization using marked() on elements with the .nb-markdown-cell class. During this process, links containing schemes such as javascript: can be regenerated. As a result, when a victim views an attacker-crafted .ipynb file and clicks the link, arbitrary JavaScript is executed in the Gogs origin, leading to a click-based Stored XSS. This vulnerability is fixed in 0.14.3.
🎖@cveNotify
GitHub
security: upgrade marked.js to 4.3.0 (#8319) · gogs/gogs@17b168b
The painless way to host your own Git service. Contribute to gogs/gogs development by creating an account on GitHub.
🚨 CVE-2026-11999
X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.
🎖@cveNotify
X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.
🎖@cveNotify
GitHub
Fixes for OpenSSL compatibility layer by Frauschi · Pull Request #10674 · wolfSSL/wolfssl
Various fixes and hardening for the OpenSSL compatibility layer. Adds regression tests as well.
Fixes zd21920.
Fixes zd21920.
🚨 CVE-2026-47770
jq is a command-line JSON processor. Prior to 1.8.2, comparing two sufficiently deeply nested arrays with the == operator exhausts the C stack on jq's ordinary command-line surface, resulting in denial of service via stack exhaustion (uncontrolled recursion). The crash occurs in jq's recursive structural comparison code, with the recursion repeating through jvp_array_equal() and jv_equal() in src/jv.c when comparing deeply nested arrays; a nearby sort comparator path through jv_cmp() in src/jv_aux.c overflows the stack at a larger nesting depth from the same missing recursion guard. Anyone running jq comparisons on attacker-controlled deeply nested JSON values, or embedding jq in a context where untrusted data can reach the == comparison path, is affected. This vulnerability is fixed in 1.8.2.
🎖@cveNotify
jq is a command-line JSON processor. Prior to 1.8.2, comparing two sufficiently deeply nested arrays with the == operator exhausts the C stack on jq's ordinary command-line surface, resulting in denial of service via stack exhaustion (uncontrolled recursion). The crash occurs in jq's recursive structural comparison code, with the recursion repeating through jvp_array_equal() and jv_equal() in src/jv.c when comparing deeply nested arrays; a nearby sort comparator path through jv_cmp() in src/jv_aux.c overflows the stack at a larger nesting depth from the same missing recursion guard. Anyone running jq comparisons on attacker-controlled deeply nested JSON values, or embedding jq in a context where untrusted data can reach the == comparison path, is affected. This vulnerability is fixed in 1.8.2.
🎖@cveNotify
GitHub
stack overflow in deep structural equality
## Summary
Comparing two sufficiently deep nested arrays with `==` on jq commit
`5f2a14dd1b03a8b43015058ed006dd4ab24fb58f` (`jq-1.8.2rc1`) still exhausts the
C stack on jq's ordinary `jq -...
Comparing two sufficiently deep nested arrays with `==` on jq commit
`5f2a14dd1b03a8b43015058ed006dd4ab24fb58f` (`jq-1.8.2rc1`) still exhausts the
C stack on jq's ordinary `jq -...
🚨 CVE-2026-48995
pnpm is a package manager. Prior to 10.33.4 and 11.0.7, a malicious codeload.github.com server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile. The lockfile does not store the hash of the dependencies from https://codeload.github.com. This means that if this server was compromised or a person's machine configuration was compromised, pnpm would download and install these dependencies. This vulnerability is fixed in 10.33.4 and 11.0.7.
🎖@cveNotify
pnpm is a package manager. Prior to 10.33.4 and 11.0.7, a malicious codeload.github.com server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile. The lockfile does not store the hash of the dependencies from https://codeload.github.com. This means that if this server was compromised or a person's machine configuration was compromised, pnpm would download and install these dependencies. This vulnerability is fixed in 10.33.4 and 11.0.7.
🎖@cveNotify
GitHub
Tarball hash of GitHub git dependencies is not stored in lockfile
### Summary
A malicious `codeload.github.com` server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile.
### Details
The lockfile does not store the ha...
A malicious `codeload.github.com` server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile.
### Details
The lockfile does not store the ha...
🚨 CVE-2026-49839
jq is a command-line JSON processor. Prior to 1.8.2,` jq --rawfile` can turn a handled oversized-string error into invalid-state reuse and a real heap out-of-bounds write in assertion-disabled builds. When jv_load_file(raw=1) reads an attacker-controlled file, it repeatedly appends file chunks to the same jv string accumulator. Once jv_string_append_buf() returns jv_invalid_with_msg("String too long"), the raw-file loop does not stop. If the file contains at least one more byte, the next loop iteration appends a new chunk to an object that is already invalid. With assertions enabled this aborts in jvp_string_ptr(). With assertions disabled, the invalid object is interpreted as a string object and ASan reports heap-buffer-overflow. This vulnerability is fixed in 1.8.2.
🎖@cveNotify
jq is a command-line JSON processor. Prior to 1.8.2,` jq --rawfile` can turn a handled oversized-string error into invalid-state reuse and a real heap out-of-bounds write in assertion-disabled builds. When jv_load_file(raw=1) reads an attacker-controlled file, it repeatedly appends file chunks to the same jv string accumulator. Once jv_string_append_buf() returns jv_invalid_with_msg("String too long"), the raw-file loop does not stop. If the file contains at least one more byte, the next loop iteration appends a new chunk to an object that is already invalid. With assertions enabled this aborts in jvp_string_ptr(). With assertions disabled, the invalid object is interpreted as a string object and ASan reports heap-buffer-overflow. This vulnerability is fixed in 1.8.2.
🎖@cveNotify
GitHub
jq --rawfile invalid-state reuse after String too long causes heap-buffer-overflow
### Summary
`jq --rawfile` can turn a handled oversized-string error into invalid-state reuse and a real heap out-of-bounds write in assertion-disabled builds.
When `jv_load_file(raw=1)` read...
`jq --rawfile` can turn a handled oversized-string error into invalid-state reuse and a real heap out-of-bounds write in assertion-disabled builds.
When `jv_load_file(raw=1)` read...
🚨 CVE-2026-50014
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=<command>. For SSH and local transports, --upload-pack can execute the supplied command. HTTPS transports ignore --upload-pack, so the practical attack surface is primarily SSH or local git dependencies. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=<command>. For SSH and local transports, --upload-pack can execute the supplied command. HTTPS transports ignore --upload-pack, so the practical attack surface is primarily SSH or local git dependencies. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
GitHub
Git Fetch Argument Injection via Lockfile resolution.commit
## Summary
pnpm passes the lockfile-controlled git `resolution.commit` value to `git fetch` without a `--` separator or commit-format validation. For git dependencies fetched through the shallow...
pnpm passes the lockfile-controlled git `resolution.commit` value to `git fetch` without a `--` separator or commit-format validation. For git dependencies fetched through the shallow...
🚨 CVE-2026-50015
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's patch application pipeline (@pnpm/patch-package) performs no path validation on file paths extracted from .patch files. An attacker who contributes a malicious patch file via a pull request can write attacker-controlled content to or delete arbitrary files on the filesystem during pnpm install, as the user running the install. The diff --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's patch application pipeline (@pnpm/patch-package) performs no path validation on file paths extracted from .patch files. An attacker who contributes a malicious patch file via a pull request can write attacker-controlled content to or delete arbitrary files on the filesystem during pnpm install, as the user running the install. The diff --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
GitHub
Arbitrary File Write/Delete via Malicious Patch File (Path Traversal)
## Summary
pnpm's patch application pipeline (`@pnpm/patch-package`) performs no path validation on file paths extracted from `.patch` files. An attacker who contributes a malicious patch fi...
pnpm's patch application pipeline (`@pnpm/patch-package`) performs no path validation on file paths extracted from `.patch` files. An attacker who contributes a malicious patch fi...
🚨 CVE-2026-50016
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install --ignore-scripts` to replace paths in the current project with symlinks to attacker-controlled dependency package directories. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install --ignore-scripts` to replace paths in the current project with symlinks to attacker-controlled dependency package directories. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
GitHub
Transitive dependency alias path traversal allows project path override via symlink replacement
## Summary
pnpm allows a transitive dependency alias from registry package metadata to
contain path traversal segments. During install, pnpm later uses that alias as a
filesystem path when lin...
pnpm allows a transitive dependency alias from registry package metadata to
contain path traversal segments. During install, pnpm later uses that alias as a
filesystem path when lin...
🚨 CVE-2026-50017
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user's npm config contains a default registry and an unscoped _authToken. The repository does not provide a token-bearing auth line. It only sets registry= to a different registry URL. During normal pnpm metadata/install workflows, pnpm binds the user-origin unscoped credential to the repository-selected registry and sends it as an Authorization header. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user's npm config contains a default registry and an unscoped _authToken. The repository does not provide a token-bearing auth line. It only sets registry= to a different registry URL. During normal pnpm metadata/install workflows, pnpm binds the user-origin unscoped credential to the repository-selected registry and sends it as an Authorization header. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
GitHub
pnpm binds unscoped user-level npm auth credentials to a repository-selected registry
Reporter: JUNYI LIU
## Summary
pnpm can send user-level unscoped npm authentication credentials to a registry
chosen by a repository-local `.npmrc` file.
In the reproduced case, the user&...
## Summary
pnpm can send user-level unscoped npm authentication credentials to a registry
chosen by a repository-local `.npmrc` file.
In the reproduced case, the user&...
🚨 CVE-2026-50021
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm's npm ci enforces integrity by default; pnpm's behavior of silently skipping verification is a pnpm-specific fail-open gap. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm's npm ci enforces integrity by default; pnpm's behavior of silently skipping verification is a pnpm-specific fail-open gap. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
GitHub
Integrity Check Bypass via Missing Lockfile Integrity Field
## Summary
pnpm's tarball extraction worker skips integrity verification when the `integrity` field is absent from the lockfile resolution. If an attacker can both modify `pnpm-lock.yaml` to...
pnpm's tarball extraction worker skips integrity verification when the `integrity` field is absent from the lockfile resolution. If an attacker can both modify `pnpm-lock.yaml` to...
🚨 CVE-2026-50573
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0.
🎖@cveNotify
GitHub
Unsafe default behavior breaks integrity check
I am not sure whether this should be classified as a vulnerability, but I am reporting it through this channel because the current behavior might be an unsafe default behavior.
## Summary
`pn...
## Summary
`pn...
🚨 CVE-2026-54679
jq is a command-line JSON processor. Prior to 1.8.2, on 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun. This vulnerability is fixed in 1.8.2.
🎖@cveNotify
jq is a command-line JSON processor. Prior to 1.8.2, on 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun. This vulnerability is fixed in 1.8.2.
🎖@cveNotify
GitHub
potential integer overflow in jvp_string_append
### Summary
On 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun.
### Details
In `src/jv.c`, the function `jvp_string...
On 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun.
### Details
In `src/jv.c`, the function `jvp_string...
🚨 CVE-2026-55180
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm and pacquet expanded ${ENV_VAR} placeholders from repository-controlled .npmrc and pnpm-workspace.yaml into registry request destinations and registry credentials. A malicious repository could cause dependency resolution to send victim environment secrets to an attacker-selected registry before lifecycle scripts run. This vulnerability is fixed in 10.34.2 and 11.5.3.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm and pacquet expanded ${ENV_VAR} placeholders from repository-controlled .npmrc and pnpm-workspace.yaml into registry request destinations and registry credentials. A malicious repository could cause dependency resolution to send victim environment secrets to an attacker-selected registry before lifecycle scripts run. This vulnerability is fixed in 10.34.2 and 11.5.3.
🎖@cveNotify
GitHub
CAND-PNPM-122: Repository config can expand victim environment secrets into registry requests before scripts run
<!-- maintainer-action:start -->
## Maintainer Action Plan
This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the det...
## Maintainer Action Plan
This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the det...
🚨 CVE-2026-55487
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value. This vulnerability is fixed in 10.34.2 and 11.5.3.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value. This vulnerability is fixed in 10.34.2 and 11.5.3.
🎖@cveNotify
GitHub
CAND-PNPM-123: manifest identity spoof satisfies allowBuilds and runs attacker lifecycle
## Summary
Keep build approval for opaque dependency sources byte-exact for GHSA-5wx6-mg75-v57r / CAND-PNPM-123.
Merged upstream commit `bf1b731ee6` fixed the original name-only approval bypa...
Keep build approval for opaque dependency sources byte-exact for GHSA-5wx6-mg75-v57r / CAND-PNPM-123.
Merged upstream commit `bf1b731ee6` fixed the original name-only approval bypa...
🚨 CVE-2026-55697
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
CAND-PNPM-097: Repository-controlled configDependencies can select a pacquet native install engine
<!-- maintainer-action:start -->
## Maintainer Action Plan
This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the det...
## Maintainer Action Plan
This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the det...
🚨 CVE-2026-55698
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3.
🎖@cveNotify
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3.
🎖@cveNotify
GitHub
CAND-PNPM-063: Project env lockfile can short-circuit package-manager resolution and execute lockfile-selected pnpm bytes
<!-- maintainer-action:start -->
## Maintainer Action Plan
This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the det...
## Maintainer Action Plan
This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the det...
🚨 CVE-2026-55700
pnpm is a package manager. From 11.3.0 until 11.5.3, `pnpm stage download` derived a local filename from registry-controlled package name and version fields. A crafted manifest could escape the selected download directory and overwrite another reachable file. The merged fix validates both fields, derives one safe filename, and verifies the final destination before writing. This vulnerability is fixed in 11.5.3.
🎖@cveNotify
pnpm is a package manager. From 11.3.0 until 11.5.3, `pnpm stage download` derived a local filename from registry-controlled package name and version fields. A crafted manifest could escape the selected download directory and overwrite another reachable file. The merged fix validates both fields, derives one safe filename, and verifies the final destination before writing. This vulnerability is fixed in 11.5.3.
🎖@cveNotify
GitHub
fix: validate staged tarball filenames by zkochan · Pull Request #12303 · pnpm/pnpm
Summary
validate package names and versions from staged tarball manifests before deriving tarball filenames
constrain pnpm stage download output paths to the selected download directory
add regres...
validate package names and versions from staged tarball manifests before deriving tarball filenames
constrain pnpm stage download output paths to the selected download directory
add regres...
🚨 CVE-2026-55961
wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles.
🎖@cveNotify
wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles.
🎖@cveNotify
GitHub
Various fixes by Frauschi · Pull Request #10702 · wolfSSL/wolfssl
Hardening and correctness fixes for certificate, TLS, and crypto paths
A set of defensive fixes across several subsystems, each in its own commit with an accompanying regression test:
PKCS7: stric...
A set of defensive fixes across several subsystems, each in its own commit with an accompanying regression test:
PKCS7: stric...
🚨 CVE-2026-55967
AES-GCM encryption/decryption with extremely large cumulative single message sizes (>64 GiB) were not properly rejected by the streaming APIs, allowing counter wrap, keystream reuse, and consequent plaintext recovery.
🎖@cveNotify
AES-GCM encryption/decryption with extremely large cumulative single message sizes (>64 GiB) were not properly rejected by the streaming APIs, allowing counter wrap, keystream reuse, and consequent plaintext recovery.
🎖@cveNotify
GitHub
20260616-aes-fixes by douzzer · Pull Request #10709 · wolfSSL/wolfssl
wolfcrypt/src/aes.c: catch and error on total length overflow in wc_AesGcmEncryptUpdate(), wc_AesGcmDecryptUpdate(), wc_AesCcmEncrypt(), and wc_AesCcmEncrypt().
tested with
wolfssl-multi-test.sh .....
tested with
wolfssl-multi-test.sh .....
🚨 CVE-2026-6091
Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled.
🎖@cveNotify
Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled.
🎖@cveNotify
GitHub
Fix partial chain verification by embhorn · Pull Request #10170 · wolfSSL/wolfssl
Description
The chain is now only accepted at a partial-chain terminal if ctx->current_cert is itself in the original trust set.
Fixes zd21566
Testing
Added new test in test_wolfSSL_X509_STO...
The chain is now only accepted at a partial-chain terminal if ctx->current_cert is itself in the original trust set.
Fixes zd21566
Testing
Added new test in test_wolfSSL_X509_STO...