π¨ CVE-2026-54094
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.14, it does not stop the HTTP file handlers from following symbolic links before they open, serve, write, share, or list a file. As a result, a scoped user β and in some cases an unauthenticated public-share recipient β can cross the intended scope boundary by following a symlink whose path is lexically inside their scope but whose target is outside it. This vulnerability is fixed in 2.63.14.
π@cveNotify
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.14, it does not stop the HTTP file handlers from following symbolic links before they open, serve, write, share, or list a file. As a result, a scoped user β and in some cases an unauthenticated public-share recipient β can cross the intended scope boundary by following a symlink whose path is lexically inside their scope but whose target is outside it. This vulnerability is fixed in 2.63.14.
π@cveNotify
GitHub
Symlinked directories let scoped users and public-share recipients read and write files outside their scope
## Summary
File Browser enforces per-user scope with `afero.NewBasePathFs(afero.NewOsFs(), scope)`, set up in `users/users.go`. This blocks lexical `../` traversal, but it does not stop the HTTP...
File Browser enforces per-user scope with `afero.NewBasePathFs(afero.NewOsFs(), scope)`, set up in `users/users.go`. This blocks lexical `../` traversal, but it does not stop the HTTP...
π¨ CVE-2026-54096
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.7, `POST /api/share/<path>` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/<hash>`. This vulnerability is fixed in 2.63.7.
π@cveNotify
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.7, `POST /api/share/<path>` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/<hash>`. This vulnerability is fixed in 2.63.7.
π@cveNotify
GitHub
Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path
### Summary
This is similar vulnrability of **`CVE-2026-0035`**, which was fixed in Android `MediaProvider` with **high** severity. In the original Java issue, `MediaStore.createWriteRequest()` ac...
This is similar vulnrability of **`CVE-2026-0035`**, which was fixed in Android `MediaProvider` with **high** severity. In the original Java issue, `MediaStore.createWriteRequest()` ac...
π¨ CVE-2026-54097
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.6, a low-privileged authenticated user of filebrowser (with create + delete permissions in their own isolated scope) can silently destroy share-link records belonging to any other user β including the administrator β by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored share.Link.Path. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped. This vulnerability is fixed in 2.63.6.
π@cveNotify
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.6, a low-privileged authenticated user of filebrowser (with create + delete permissions in their own isolated scope) can silently destroy share-link records belonging to any other user β including the administrator β by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored share.Link.Path. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped. This vulnerability is fixed in 2.63.6.
π@cveNotify
GitHub
fix: cross-user unauthorized share-link deletion Β· filebrowser/filebrowser@0231b7e
π Web File Browser. Contribute to filebrowser/filebrowser development by creating an account on GitHub.
π¨ CVE-2026-54250
K3s is a fully conformant production-ready Kubernetes distribution. Prior to 1.35.3+k3s1, 1.34.6+k3s1, v1.33.10+k3s1, a path traversal vulnerability exists in K3s's etcd snapshot decompression functionality. Zip files containing archive members with maliciously crafted names can be written to arbitrary locations on the filesystem when an administrator restores the archive as a compressed etcd snapshot. This vulnerability is fixed in 1.35.3+k3s1, 1.34.6+k3s1, v1.33.10+k3s1.
π@cveNotify
K3s is a fully conformant production-ready Kubernetes distribution. Prior to 1.35.3+k3s1, 1.34.6+k3s1, v1.33.10+k3s1, a path traversal vulnerability exists in K3s's etcd snapshot decompression functionality. Zip files containing archive members with maliciously crafted names can be written to arbitrary locations on the filesystem when an administrator restores the archive as a compressed etcd snapshot. This vulnerability is fixed in 1.35.3+k3s1, 1.34.6+k3s1, v1.33.10+k3s1.
π@cveNotify
GitHub
ZIP Archive Path Traversal Vulnerability in etcd Snapshot Decompression
#### Summary
A path traversal vulnerability exists in K3s's etcd snapshot decompression functionality. Zip files containing archive members with maliciously crafted names (e.g., `../../../.....
A path traversal vulnerability exists in K3s's etcd snapshot decompression functionality. Zip files containing archive members with maliciously crafted names (e.g., `../../../.....
π¨ CVE-2026-54917
SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables. Prior to 4.30, the S3 API gateway and the Iceberg REST catalog gateway construct their routers with mux.NewRouter().SkipClean(true). With path cleaning disabled, a .. segment inside the URL survives routing, so a request such as `GET /bucket-A/../evil-bucket/key`, is matched as bucket=bucket-A, object=../evil-bucket/key. The captured object key is then joined into a filer path with util.JoinPath (S3) / path.Join (Iceberg), which collapse the .. server-side, so the actual read or write lands in evil-bucket. This vulnerability is fixed in 4.30.
π@cveNotify
SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables. Prior to 4.30, the S3 API gateway and the Iceberg REST catalog gateway construct their routers with mux.NewRouter().SkipClean(true). With path cleaning disabled, a .. segment inside the URL survives routing, so a request such as `GET /bucket-A/../evil-bucket/key`, is matched as bucket=bucket-A, object=../evil-bucket/key. The captured object key is then joined into a filer path with util.JoinPath (S3) / path.Join (Iceberg), which collapse the .. server-side, so the actual read or write lands in evil-bucket. This vulnerability is fixed in 4.30.
π@cveNotify
GitHub
s3,iceberg: reject `..` in URL path vars by chrislusf Β· Pull Request #9687 Β· seaweedfs/seaweedfs
Summary
Both gateway routers run with mux.NewRouter().SkipClean(true) (weed/command/s3.go:304,523), so a request like
GET /bucket-A/../evil-bucket/key
survives routing as bucket=bucket-A, object=....
Both gateway routers run with mux.NewRouter().SkipClean(true) (weed/command/s3.go:304,523), so a request like
GET /bucket-A/../evil-bucket/key
survives routing as bucket=bucket-A, object=....
π¨ CVE-2026-55667
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.16, a scoped, non-admin File Browser user holding only the Create permission can delete arbitrary files outside their scope (other tenants' data, and the application's own database) via the upload failure-cleanup path. ScopedFs.RemoveAll is the one dereferencing operation that skips the symlink guard every other method enforces. The direct-upload handler runs RemoveAll on the user-controlled path during failed-upload cleanup, gated only by Perm.Create. If an escaping directory symlink already exists inside the user's scope, an authenticated create-only user can delete an out-of-scope target, bypassing both the ScopedFs boundary and the Perm.Delete gate. This vulnerability is fixed in 2.63.16.
π@cveNotify
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.16, a scoped, non-admin File Browser user holding only the Create permission can delete arbitrary files outside their scope (other tenants' data, and the application's own database) via the upload failure-cleanup path. ScopedFs.RemoveAll is the one dereferencing operation that skips the symlink guard every other method enforces. The direct-upload handler runs RemoveAll on the user-controlled path during failed-upload cleanup, gated only by Perm.Create. If an escaping directory symlink already exists inside the user's scope, an authenticated create-only user can delete an out-of-scope target, bypassing both the ScopedFs boundary and the Perm.Delete gate. This vulnerability is fixed in 2.63.16.
π@cveNotify
GitHub
Out-of-scope file deletion by a Create-only scoped user via symlink-following RemoveAll in upload failure-cleanup
## Summary
A scoped, non-admin File Browser user holding only the **Create** permission can delete arbitrary files outside their scope (other tenants' data, and the application's own dat...
A scoped, non-admin File Browser user holding only the **Create** permission can delete arbitrary files outside their scope (other tenants' data, and the application's own dat...
π¨ CVE-2026-57700
Unrestricted Upload of File with Dangerous Type vulnerability in Daan.Dev OMGF Pro allows Using Malicious Files.
This issue affects OMGF Pro: from n/a through 5.2.6.
π@cveNotify
Unrestricted Upload of File with Dangerous Type vulnerability in Daan.Dev OMGF Pro allows Using Malicious Files.
This issue affects OMGF Pro: from n/a through 5.2.6.
π@cveNotify
Patchstack
Arbitrary File Upload in WordPress OMGF Pro Plugin
Patchstack is the leading open source vulnerability research organization. Find information and protection for all WordPress, Drupal and Joomla security issues.
π¨ CVE-2025-60464
A use-after-free in the gf_sei_load_from_state_internal function (/filters/sei_load.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MPEG-2 TS file.
π@cveNotify
A use-after-free in the gf_sei_load_from_state_internal function (/filters/sei_load.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MPEG-2 TS file.
π@cveNotify
GitHub
fixed #3278 Β· gpac/gpac@8f404bd
GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery - fixed #3278 Β· gpac/gpac@8f404bd
π¨ CVE-2025-60465
A use-after-free in the gf_filter_pid_inst_swap function (/filter_core/filter_pid.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted media file.
π@cveNotify
A use-after-free in the gf_filter_pid_inst_swap function (/filter_core/filter_pid.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted media file.
π@cveNotify
GitHub
Fixed #3283 Β· gpac/gpac@55b351b
GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery - Fixed #3283 Β· gpac/gpac@55b351b
π¨ CVE-2026-10097
ML-KEM-1024 x64 AVX2 implicit rejection failure in the Fujisaki-Okamoto transform breaks IND-CCA2 security, allowing decapsulation to deviate from the implicit-rejection behavior required by the standard. The AVX2 constant-time ciphertext comparison used during decapsulation never compared the final 32-byte block of the 1568-byte ML-KEM-1024 ciphertext, so a ciphertext manipulated only in those final bytes would compare as equal and decapsulation returned the real shared secret instead of performing the required implicit rejection.
π@cveNotify
ML-KEM-1024 x64 AVX2 implicit rejection failure in the Fujisaki-Okamoto transform breaks IND-CCA2 security, allowing decapsulation to deviate from the implicit-rejection behavior required by the standard. The AVX2 constant-time ciphertext comparison used during decapsulation never compared the final 32-byte block of the 1568-byte ML-KEM-1024 ciphertext, so a ciphertext manipulated only in those final bytes would compare as equal and decapsulation returned the real shared secret instead of performing the required implicit rejection.
π@cveNotify
GitHub
ML-KEM: fix AVX2 assembly by SparkiDev Β· Pull Request #10430 Β· wolfSSL/wolfssl
Description
AVX2 not decompressing 5-bit values correctly.
AVX2 not comparing last 32 bytes of ciphertext.
Protect mlkemkey_get_k to only be compiled when make key is compiled in.
Fixes zd#21471
Te...
AVX2 not decompressing 5-bit values correctly.
AVX2 not comparing last 32 bytes of ciphertext.
Protect mlkemkey_get_k to only be compiled when make key is compiled in.
Fixes zd#21471
Te...
π¨ CVE-2026-10512
The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical.
π@cveNotify
The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical.
π@cveNotify
GitHub
X25519 x64 ASM: fix full reduction by SparkiDev Β· Pull Request #10536 Β· wolfSSL/wolfssl
Description
The last add was overflowing into the top bit.
Must mask the last word to clear top bit.
Add test vectors from Wycheproof.
Fixes zd#21864
Testing
Added KATs to test_curve25519.c
Tests n...
The last add was overflowing into the top bit.
Must mask the last word to clear top bit.
Add test vectors from Wycheproof.
Fixes zd#21864
Testing
Added KATs to test_curve25519.c
Tests n...
π¨ CVE-2026-10592
Certificates with wildcard DNS SANs (e.g. *.example.com) bypassed CA name-constraint checks. A certificate with a wildcard DNS SAN that should be rejected by the issuing CA's permitted/excluded DNS name constraints could be accepted.
π@cveNotify
Certificates with wildcard DNS SANs (e.g. *.example.com) bypassed CA name-constraint checks. A certificate with a wildcard DNS SAN that should be rejected by the issuing CA's permitted/excluded DNS name constraints could be accepted.
π@cveNotify
GitHub
NameConstraints: support wildcard SAN by rizlik Β· Pull Request #10549 Β· wolfSSL/wolfssl
Description
Proper NameConstraint checking in case of wildcard in the SAN DNS types
Proper NameConstraint checking in case of wildcard in the SAN DNS types
π¨ CVE-2026-11310
X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.
π@cveNotify
X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.
π@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-12340
Out-of-bounds heap read during SM2/SM3 certificate signature verification. When parsing a certificate with an SM3wSM2 signature, the Subject Key Identifier computation reads the trailing 65 bytes of the public key without checking that the key is at least that long. A public key shorter than 65 bytes results in an out-of-bounds heap read, leading to a potential crash (denial of service); there is no out-of-bounds write. Note this only affects builds with SM2 support (--enable-sm2 or --enable-all).
π@cveNotify
Out-of-bounds heap read during SM2/SM3 certificate signature verification. When parsing a certificate with an SM3wSM2 signature, the Subject Key Identifier computation reads the trailing 65 bytes of the public key without checking that the key is at least that long. A public key shorter than 65 bytes results in an out-of-bounds heap read, leading to a potential crash (denial of service); there is no out-of-bounds write. Note this only affects builds with SM2 support (--enable-sm2 or --enable-all).
π@cveNotify
GitHub
Fixes for SM2/3 and FindMultiAttrib by rlm2002 Β· Pull Request #10641 Β· wolfSSL/wolfssl
Description
Prevent potential heap-buffer-overflow (out of bounds read) when SM2/SM3 is enabled. Reject a certificate with an SM3wSM2 signatureAlgorithm and a public key shorter than 65 bytes, (cer...
Prevent potential heap-buffer-overflow (out of bounds read) when SM2/SM3 is enabled. Reject a certificate with an SM3wSM2 signatureAlgorithm and a public key shorter than 65 bytes, (cer...
π¨ CVE-2026-2299
The Mattermost Google Drive plugin before version 1.1.0 fails to validate channel membership in the file creation endpoint, allowing authenticated users with a connected Google account to share Google Drive files to unauthorized private channels and disclose private channel membership.
π@cveNotify
The Mattermost Google Drive plugin before version 1.1.0 fails to validate channel membership in the file creation endpoint, allowing authenticated users with a connected Google account to share Google Drive files to unauthorized private channels and disclose private channel membership.
π@cveNotify
GitHub
Release v1.1.0 Β· mattermost/mattermost-plugin-google-drive
Supported Mattermost Server Versions: 6.2.1+
Enhancements
Fixes
c8e4c79 Auto generate version based on git info (#55)
8cbbb61 Delete .github/workflows/cd.yml (#54)
2fe647c Mark confidential settin...
Enhancements
Fixes
c8e4c79 Auto generate version based on git info (#55)
8cbbb61 Delete .github/workflows/cd.yml (#54)
2fe647c Mark confidential settin...
π¨ CVE-2026-37149
GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN v1.0 was discovered to contain a SQL injection vulnerability in the scost parameter in /grocery/search_products.php. This vulnerability allows attackers to access sensitive database information via a crafted SQL statement.
π@cveNotify
GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN v1.0 was discovered to contain a SQL injection vulnerability in the scost parameter in /grocery/search_products.php. This vulnerability allows attackers to access sensitive database information via a crafted SQL statement.
π@cveNotify
GitHub
GitHub - anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN-: This project contains my project workβ¦
This project contains my project work on a grocery store management system done on PHP and MYSQL using XAMPP AND PHPMYADMIN - anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHP...
π¨ CVE-2026-37454
Insecure Permissions vulnerability in MSI NBFoundation Service v.2.0.2506.1201 allows a remote attacker to obtain sensitive information via the 3DES-ECB encryption
π@cveNotify
Insecure Permissions vulnerability in MSI NBFoundation Service v.2.0.2506.1201 allows a remote attacker to obtain sensitive information via the 3DES-ECB encryption
π@cveNotify
π¨ CVE-2026-46601
The webp decoder can panic when processing a VP8 chunk with dimensions that do not match the canvas size.
π@cveNotify
The webp decoder can panic when processing a VP8 chunk with dimensions that do not match the canvas size.
π@cveNotify
π¨ CVE-2026-46602
The TIFF decoder does not set a limit on the size of tiles in tiled images, permitting a malicious or corrupt image containing a very large tile to cause unbounded memory consumption.
π@cveNotify
The TIFF decoder does not set a limit on the size of tiles in tiled images, permitting a malicious or corrupt image containing a very large tile to cause unbounded memory consumption.
π@cveNotify
π¨ CVE-2026-55958
Out-of-bounds write in the Renesas TSIP TLS 1.3 transcript buffer. In tsip_StoreMessage() the capacity check guarding the fixed message bag (MSGBAG_SIZE) sets an error code but fails to return, so execution falls through to an XMEMCPY that writes past the end of the buffer once the accumulated TLS 1.3 handshake transcript exceeds MSGBAG_SIZE (8 KB), corrupting adjacent heap state and potentially causing a remote denial of service crash. The bag is sized to hold a normal handshake, so this is reached only by an unusually large but valid certificate chain, or by a malicious or man-in-the-middle server sending an oversized handshake message to a client that does not strictly verify the chain. This only affects builds using the Renesas TSIP TLS port (WOLFSSL_RENESAS_TSIP_TLS) as a TLS 1.3 client on Renesas MCUs with TSIP hardware enabled, and is rated High within those builds. All other configurations are unaffected.
π@cveNotify
Out-of-bounds write in the Renesas TSIP TLS 1.3 transcript buffer. In tsip_StoreMessage() the capacity check guarding the fixed message bag (MSGBAG_SIZE) sets an error code but fails to return, so execution falls through to an XMEMCPY that writes past the end of the buffer once the accumulated TLS 1.3 handshake transcript exceeds MSGBAG_SIZE (8 KB), corrupting adjacent heap state and potentially causing a remote denial of service crash. The bag is sized to hold a normal handshake, so this is reached only by an unusually large but valid certificate chain, or by a malicious or man-in-the-middle server sending an oversized handshake message to a client that does not strictly verify the chain. This only affects builds using the Renesas TSIP TLS port (WOLFSSL_RENESAS_TSIP_TLS) as a TLS 1.3 client on Renesas MCUs with TSIP hardware enabled, and is rated High within those builds. All other configurations are unaffected.
π@cveNotify
GitHub
Renesas TSIP: skip XMEMCPY on MEMORY_E from tsip_StoreMessage() by cconlon Β· Pull Request #10705 Β· wolfSSL/wolfssl
Description
This PR fixes the Renesas TSIP port's tsip_StoreMessage() to skip calling XMEMCPY when buffer sanity checks have failed.
Fixes item 9 from ZD 21992.
Checklist
added tests
upd...
This PR fixes the Renesas TSIP port's tsip_StoreMessage() to skip calling XMEMCPY when buffer sanity checks have failed.
Fixes item 9 from ZD 21992.
Checklist
added tests
upd...
π¨ CVE-2026-55960
Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all.
π@cveNotify
Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all.
π@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...