CVE-2024-2048
published 2024-03-04CVE-2024-2048: Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as…
PriorityP351critical9.8CVSS 3.1
AVNACLPRNUINSUCHIHAH
EPSS
0.45%
35.7th percentile
Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| github.com | hashicorp_vault | >= 0 < 1.14.10 | 1.14.10 |
| github.com | hashicorp_vault | >= 1.15.0 < 1.15.5 | 1.15.5 |
| hashicorp | vault | < 1.14.10 | 1.14.10 |
| hashicorp | vault | >= 1.15.0 < 1.15.5 | 1.15.5 |
| hashicorp | vault | >= 1.15.5 < 1.16.0 | 1.16.0 |
| hashicorp | vault_enterprise | >= 1.15.5 < 1.16.0 | 1.16.0 |
| latchset | jwcrypto | >= 0 < 1.5.6 | 1.5.6 |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| openbao | openbao | < 2.0.0 | 2.0.0 |
CVSS provenance
nvdv3.19.8CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vendor_redhat8.1HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2024-26713: In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add
When a PCI devi
osv·2024-04-03
CVE-2024-26713 CVE-2024-26713: In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add
When a PCI devi
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add
When a PCI device is dynamically added, the kernel oopses with a NULL
pointer dereference:
BUG: Kernel NULL pointer dereference on read at 0x00000030
Faulting instruction address: 0xc0000000006bbe5c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs
OSV
Authentication bypass in github.com/hashicorp/vault
osv·2024-03-14
CVE-2024-2048 Authentication bypass in github.com/hashicorp/vault
Authentication bypass in github.com/hashicorp/vault
The TLS certificate authentication method incorrectly validates client certificates when configured with a non-CA certificate as a trusted certificate. When configured this way, attackers may be able to craft a certificate that can be used to bypass authentication.
GHSA
JWCrypto vulnerable to JWT bomb Attack in `deserialize` function
ghsa·2024-03-06
CVE-2024-28102 [MEDIUM] CWE-770 JWCrypto vulnerable to JWT bomb Attack in `deserialize` function
JWCrypto vulnerable to JWT bomb Attack in `deserialize` function
## Affected version
Vendor: https://github.com/latchset/jwcrypto
Version: 1.5.5
## Description
An attacker can cause a DoS attack by passing in a malicious JWE Token with a high compression ratio.
When the server processes this Token, it will consume a lot of memory and processing time.
## Poc
```python
from jwcrypto import jwk, jwe
from jwcrypto.common import json_encode, json_decode
import time
public_key = jwk.JWK()
private_key = jwk.JWK.generate(kty='RSA', size=2048)
public_key.import_key(**json_decode(private_key.export_public()))
payload = '{"u": "' + "u" * 400000000 + '", "uu":"' + "u" * 400000000 + '"}'
protected_header = {
"alg": "RSA-OAEP-256",
"enc": "A256CBC-HS512",
"typ": "JWE",
"zip": "DEF",
"kid": public_k
GHSA
Incorrect TLS certificate auth method in Vault
ghsa·2024-03-04
CVE-2024-2048 [HIGH] CWE-295 Incorrect TLS certificate auth method in Vault
Incorrect TLS certificate auth method in Vault
Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.
OSV
Incorrect TLS certificate auth method in Vault
osv·2024-03-04
CVE-2024-2048 [HIGH] Incorrect TLS certificate auth method in Vault
Incorrect TLS certificate auth method in Vault
Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.
Red Hat
kernel: block: fix integer overflow in BLKSECDISCARD
vendor_redhat·2024-10-21·CVSS 5.5
CVE-2024-49994 [MEDIUM] CWE-190 kernel: block: fix integer overflow in BLKSECDISCARD
kernel: block: fix integer overflow in BLKSECDISCARD
In the Linux kernel, the following vulnerability has been resolved:
block: fix integer overflow in BLKSECDISCARD
I independently rediscovered
commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
block: fix overflow in blk_ioctl_discard()
but for secure erase.
Same problem:
uint64_t r[2] = {512, 18446744073709551104ULL};
ioctl(fd, BLKSECDISCARD, r);
will enter near infinite loop inside blkdev_issue_secure_erase():
a.out: attempt to access beyond end of device
loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048
bio_check_eod: 3286214 callbacks suppressed
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: kernel (Red Hat Enterprise Linux 7) - Out of support scope
Package: kernel-rt (Red Hat Enterprise Linux 7) - Ou
Red Hat
kernel: powerpc/pseries: Whitelist dtl slub object for copying to userspace
vendor_redhat·2024-07-29·CVSS 5.5
CVE-2024-41065 [MEDIUM] CWE-99 kernel: powerpc/pseries: Whitelist dtl slub object for copying to userspace
kernel: powerpc/pseries: Whitelist dtl slub object for copying to userspace
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM
Red Hat
kernel: media: dvb-frontends: avoid stack overflow warnings with clang
vendor_redhat·2024-05-01·CVSS 7.8
CVE-2024-27075 [HIGH] kernel: media: dvb-frontends: avoid stack overflow warnings with clang
kernel: media: dvb-frontends: avoid stack overflow warnings with clang
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar
problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both
register access functions as noinline_for_stack so the temporary
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
is enabled.
Package: kernel (Red Hat Enterprise Linux 6) - Not affe
Red Hat
hashicorp/vault: Vault Cert Auth Method Did Not Correctly Validate Non-CA Certificates
vendor_redhat·2024-03-04·CVSS 8.1
CVE-2024-2048 [HIGH] CWE-295 hashicorp/vault: Vault Cert Auth Method Did Not Correctly Validate Non-CA Certificates
hashicorp/vault: Vault Cert Auth Method Did Not Correctly Validate Non-CA Certificates
Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.
A flaw was found in Vault and Vault Enterprise's TLS certificate authentication method. This vulnerability allows an attacker to bypass authentication via a crafted malicious certificate when a non-CA certificate is used as a trusted certificate.
Statement: Note this vulnerability is in github.com/hashicorp/vault, but not in github.com/hashicorp/vault/api, which is a se
Suricata
ET EXPLOIT Possible CVE-2015-7547 Large Response to A/AAAA query
suricata·2016-02-18·CVSS 8.1
CVE-2015-7547 [HIGH] ET EXPLOIT Possible CVE-2015-7547 Large Response to A/AAAA query
ET EXPLOIT Possible CVE-2015-7547 Large Response to A/AAAA query
Rule: alert tcp any 53 -> $HOME_NET any (msg:"ET EXPLOIT Possible CVE-2015-7547 Large Response to A/AAAA query"; flow:established,to_client; flowbits:isset,ET.CVE20157547.primer; byte_test:2,>,2048,0; byte_test:1,&,128,4; byte_test:1,!&,64,4; byte_test:1,!&,32,4; byte_test:1,!&,16,4; byte_test:1,!&,8,4; content:"|00 01|"; offset:6; depth:2; reference:cve,2015-7547; classtype:attempted-user; sid:2022547; rev:2; metadata:created_at 2016_02_18, cve CVE_2015_7547, confidence Medium, signature_severity Major, updated_at 2024_03_07;)
Suricata
GPL RPC portmap proxy integer overflow attempt TCP
suricata·2010-09-23
CVE-2003-0028 GPL RPC portmap proxy integer overflow attempt TCP
GPL RPC portmap proxy integer overflow attempt TCP
Rule: alert tcp $EXTERNAL_NET any -> $HOME_NET 111 (msg:"GPL RPC portmap proxy integer overflow attempt TCP"; flow:established,to_server; content:"|00 01 86 A0 00|"; depth:5; offset:16; content:"|00 00 00 05|"; within:4; distance:3; byte_jump:4,4,relative,align; byte_jump:4,4,relative,align; byte_test:4,>,2048,12,relative; content:"|00 00 00 00|"; depth:4; offset:8; reference:bugtraq,7123; reference:cve,2003-0028; classtype:rpc-portmap-decode; sid:2102093; rev:7; metadata:created_at 2010_09_23, cve CVE_2003_0028, confidence Medium, signature_severity Informational, updated_at 2024_03_08;)
No public exploits indexed.
https://discuss.hashicorp.com/t/hcsec-2024-05-vault-cert-auth-method-did-not-correctly-validate-non-ca-certificates/63382https://security.netapp.com/advisory/ntap-20240524-0009/https://discuss.hashicorp.com/t/hcsec-2024-05-vault-cert-auth-method-did-not-correctly-validate-non-ca-certificates/63382https://security.netapp.com/advisory/ntap-20240524-0009/
2024-03-04
Published