CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
|
Description: A Threat Actor Claims to be Selling the Data of Cin Learn
February 10th, 2025 (5 months ago)
|
|
|
Description: Today, an Alabama man pleaded guilty to hijacking the U.S. Securities and Exchange Commission (SEC) account on X in a January 2024 SIM swapping attack. [...]
February 10th, 2025 (5 months ago)
|
|
|
Description: Belsen_Group is Allegedly Selling RCE Access to an Unidentified Manufacturing Company in North Africa
February 10th, 2025 (5 months ago)
|
|
|
Description: A Threat Actor Claims to have Leaked the Data and Source Code of Circuito Mágico del Agua
February 10th, 2025 (5 months ago)
|
|
|
Description: Summary
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
Details
esbuild sets Access-Control-Allow-Origin: * header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
Attack scenario:
The attacker serves a malicious web page (http://malicious.example.com).
The user accesses the malicious web page.
The attacker sends a fetch('http://127.0.0.1:8000/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.
The attacker gets the content of http://127.0.0.1:8000/main.js.
In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
Fetching /index.html: normally you have a script tag here
Fetching /assets: it's common to have a assets directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files
Connecting /esbuild SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventL...
February 10th, 2025 (5 months ago)
|
|
|
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)
|