![]() |
Description: Impact
There is a security vulnerability in outdated versions of Coinbase Wallet SDK. This does not directly affect users' keys, smart contracts, or funds.
Patches
Please update to version >= 4.3.0.
References
https://github.com/coinbase/coinbase-wallet-sdk/security/advisories/GHSA-8rgj-285w-qcq4
https://github.com/advisories/GHSA-8rgj-285w-qcq4
February 10th, 2025 (5 months ago)
|
![]() |
Description: Summary
There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.
Details
IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.
The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.
Malicious inputs:
# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"
# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"
# Numbers must be non-zero uint32, but this isn't validated. Arrays larger than
# UINT32_MAX can be created. For example, the following would theoretically
...
February 10th, 2025 (5 months ago)
|
![]() |
Description: Impact
When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash.
Workarounds
As workaround its possible to either disable the usage of the native SSLEngine or changing the code from:
SslContext context = ...;
SslHandler handler = context.newHandler(....);
to:
SslContext context = ...;
SSLEngine engine = context.newEngine(....);
SslHandler handler = new SslHandler(engine, ....);
References
https://github.com/netty/netty/security/advisories/GHSA-4g8c-wm8x-jfhw
https://github.com/netty/netty/commit/87f40725155b2f89adfde68c7732f97c153676c4
https://github.com/advisories/GHSA-4g8c-wm8x-jfhw
February 10th, 2025 (5 months ago)
|
CVE-2024-57606 |
Description: SQL injection vulnerability in Beijing Guoju Information Technology Co., Ltd JeecgBoot v.3.7.2 allows a remote attacker to obtain sensitive information via the getTotalData component.
References
https://nvd.nist.gov/vuln/detail/CVE-2024-57606
https://github.com/jeecgboot/JeecgBoot/issues/7665
https://github.com/advisories/GHSA-wfpm-qchc-6cf9
EPSS Score: 0.04%
February 10th, 2025 (5 months ago)
|
![]() |
Description: Summary
The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.
Details
verify_dnskey_rrset() will return Ok(true) if any record's public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.
Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but ...
February 10th, 2025 (5 months ago)
|
![]() |
Description: A Threat Actor Claims to have Leaked the Data of Al Tamimi & Company
February 10th, 2025 (5 months ago)
|
![]() |
Description: Learn Exploit Defaced Multiple Websites in India
February 10th, 2025 (5 months ago)
|
![]() |
Description: A global law enforcement operation targeting the Phobos ransomware gang has led to the arrest of four suspected hackers in Phuket, Thailand, and the seizure of 8Base's dark web sites. The suspects are accused of conducting cyberattacks on over 1,000 victims worldwide. [...]
February 10th, 2025 (5 months ago)
|
![]() |
Description: Authorities in Thailand, Switzerland, and the United States have dismantled a major ransomware operation, arresting four European nationals in Phuket who allegedly stole $16 million through cyber extortion. The suspects, linked to the Phobos ransomware group, were apprehended in a series of coordinated raids conducted under Operation PHOBOS AETOR on February 10, 2025. The arrests …
The post Phobos Ransomware Gang Dismantled in International Sting appeared first on CyberInsider.
February 10th, 2025 (5 months ago)
|
![]() |
Description: Lee Enterprises, one of the largest newspaper groups in the United States, says a cyberattack that hit its systems caused an outage last week and impacted its operations. [...]
February 10th, 2025 (5 months ago)
|