CVE-2024-34786 |
Description: UniFi iOS app 10.15.0 introduces a misconfiguration on 2nd Generation UniFi Access Points configured as standalone (not using UniFi Network Application) that could cause the SSID name to change and/or the WiFi Password to be removed on the 5GHz Radio.
This vulnerability is fixed in UniFi iOS app 10.15.2 and later.
EPSS Score: 0.04%
February 11th, 2025 (5 months ago)
|
CVE-2024-32268 |
Description: An issue in Tuya Smart camera U6N v.3.2.5 allows a remote attacker to cause a denial of service via a crafted packet to the network connection component.
EPSS Score: 0.04%
February 11th, 2025 (5 months ago)
|
CVE-2024-30916 |
Description: An issue was discovered in eProsima FastDDS v.2.14.0 and before, allows a local attacker to cause a denial of service (DoS) and obtain sensitive information via a crafted max_samples parameter in DurabilityService QoS component.
EPSS Score: 0.04%
February 11th, 2025 (5 months ago)
|
CVE-2024-29502 |
Description: An issue in Secure Lockdown Multi Application Edition v2.00.219 allows attackers to read arbitrary files via using UNC paths.
EPSS Score: 0.04%
February 11th, 2025 (5 months ago)
|
CVE-2024-27859 |
Description: The issue was addressed with improved memory handling. This issue is fixed in iOS 17.4 and iPadOS 17.4, tvOS 17.4, watchOS 10.4, visionOS 1.1, macOS Sonoma 14.4. Processing web content may lead to arbitrary code execution.
EPSS Score: 0.07%
February 11th, 2025 (5 months ago)
|
CVE-2024-12243 |
Description: A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.
EPSS Score: 0.05%
February 11th, 2025 (5 months ago)
|
![]() |
Description: This daily article is intended to make it easier for those who want to stay updated with my regular Dark Web Informer and X/Twitter posts.
February 11th, 2025 (5 months ago)
|
![]() |
Description: The likely Vietnam-based threat actor has been using two zero-days in VeraCore's warehouse management software in some of its latest cyberattacks.
February 10th, 2025 (5 months ago)
|
![]() |
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)
|