Most recent entries from all

bdu:2025-09867

certfr-2024-avi-1081 — De multiples vulnérabilités ont été découvertes dans les produits IBM.Certaines d'entre elles permettent à un attaquant…

certfr-2024-avi-1081

Withdrawn: CLEANSTART-2026-CU18187 — Security fixes in stargate 1.0.90-r4

Withdrawn by the publisher.

Affected: CleanStart: stargate

Package stargate version 1.0.90-r4 fixes 87 vulnerabilities: ghsa-76h9-2vwh-w278, ghsa-pqr6-cmr2-h8hf, ghsa-fjpj-2g6w-x25r, ghsa-qcwq-55hx-v3vh, ghsa-55g7-9cwv-5qfv...

EUVD-2026-248372

fkie_cve-2024-25638

dnsjava is an implementation of DNS in Java. Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. This vulnerability is fixed in 3.6.0.

GHSA-cfxw-4h78-h7fw — DNSJava DNSSEC Bypass

Affected: Maven: dnsjava:dnsjava

### Summary

Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.

### Details

DNS Messages are not authenticated. They do not guarantee that

- received RRs are authentic - not received RRs do not exist - all or any received records in a response relate to the request

Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)

1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases 2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) 3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. 4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`.

Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.

dnsjava does not implement a comparable algorithm, and the provided APIs instead return ei…

gsd-2024-25638

OESA-2024-1899 — dnsjava security update

Affected: openEuler:24.03-LTS: dnsjava

dnsjava is an implementation of DNS in Java. It supports all of the common record types and the DNSSEC types. It can be used for queries, zone transfers, and dynamic updates. It includes a cache which can be used by clients, and a minimal implementation of a server. It supports TSIG authenticated messages, partial DNSSEC verification, and EDNS0. dnsjava provides functionality above and beyond that of the InetAddress class. Since it is written in pure Java, dnsjava is fully threadable, and in many cases is faster than using InetAddress. dnsjava provides both high and low level access to DNS. The high level functions perform queries for records of a given name, type, and class, and return an array of records. There is also a clone of InetAddress, which is even simpler. A cache is used to reduce the number of DNS queries sent. The low level functions allow direct manipulation of dns messages and records, as well as allowing additional resolver properties to be set. A 'dig' clone and a dynamic update program are included, as well as a primary-only server. Security Fix(es): dnsjava is an implementation of DNS in Java. Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. This vulnerability is fixed in 3.6.0.(CVE-2024-25638)

UBUNTU-CVE-2024-25638

Affected: Ubuntu:16.04:LTS: dnsjava, Ubuntu:18.04:LTS: dnsjava, Ubuntu:20.04:LTS: dnsjava, Ubuntu:22.04:LTS: dnsjava, Ubuntu:24.04:LTS: dnsjava, Ubuntu:25.10: dnsjava, Ubuntu:26.04:LTS: dnsjava

WID-SEC-W-2024-3195 — Oracle Communications: Mehrere Schwachstellen

Ein entfernter, anonymer oder authentisierter Angreifer kann mehrere Schwachstellen in Oracle Communications ausnutzen, um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.