CVE-2023-41045
Graylog ≤ 5.0.9
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:NCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2023-41045 is a low-severity Insufficient Verification of Data Authenticity (CWE-345) vulnerability in Graylog Graylog. Its CVSS base score is 3.7 (Low).
Operationally, ranked at the 28th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-2058
Vulnerability Data
Graylog is a free and open log management platform. Graylog makes use of only one single source port for DNS queries. Graylog binds a single socket for outgoing DNS queries and while that socket is bound to a random port…
more
number it is never changed again. This goes against recommended practice since 2008, when Dan Kaminsky discovered how easy is to carry out DNS cache poisoning attacks. In order to prevent cache poisoning with spoofed DNS responses, it is necessary to maximise the uncertainty in the choice of a source port for a DNS query. Although unlikely in many setups, an external attacker could inject forged DNS responses into a Graylog's lookup table cache. In order to prevent this, it is at least recommendable to distribute the DNS queries through a pool of distinct sockets, each of them with a random source port and renew them periodically. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade. There are no known workarounds for this issue.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Directly requires independent verification of matching output before adverse decisions, mitigating insufficient authenticity checks on data from external sources.
Use of approved PKI certificates provides verifiable data authenticity and origin for communications and artifacts.
Mandates provision of authenticity and integrity artifacts that enable verification of name/address resolution data.
Requires explicit verification of data authenticity from authoritative sources, preventing acceptance of unauthenticated resolution responses.
Control requires verification of data authenticity/integrity (e.g., checksums) after aggregation/packing, directly reducing exploitation of insufficient verification before transmission.
Time synchronization supports reliable freshness verification when checking data authenticity across systems or components.
Mandates verification of data authenticity for software, firmware, and information.
Provenance documentation and monitoring directly enables verification of authenticity for components and data throughout their history.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.24's guidance on identifying protection levels, selecting algorithms/strength for authenticity/integrity (items b,f), using cryptography for transmitted/stored data (c), and key management directly stops many CWE-345 exploits by ensuring verifiable authenticity; however, it leaves a bounded remainder where verification logic itself is flawed or absent (e.g. accepting unverified signatures or weak schemes), as the control depends on correct implementation in other mechanisms.
Secure SDLC incorporates authenticity verification requirements throughout development.
Application security requirements can mandate data authenticity verification mechanisms.
Secure coding practices include implementing proper data authenticity checks.
Security testing can detect missing or weak data authenticity verification.
Secure authentication of data sources ensures only valid, authentic data is accepted.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.