CVE-2024-47619: Syslog-ng Information Disclosure Flaw

CVE-2024-47619 Overview

CVE-2024-47619 is an improper certificate validation flaw [CWE-295] in syslog-ng, an enhanced log daemon widely deployed for centralized log collection. The tls_wildcard_match() function in versions prior to 4.8.2 accepts certificate patterns that violate RFC 6125 wildcard rules. Specifically, the function matches patterns such as foo.*.bar and partial wildcards like foo.a*c.bar that should be rejected. Attackers positioned on the network path can leverage permissively issued or crafted certificates to impersonate trusted hosts. This weakens TLS authentication for syslog-ng connections and enables man-in-the-middle scenarios against log transport channels.

Critical Impact

Attackers with network position can intercept or manipulate syslog-ng TLS traffic by presenting certificates with overly broad wildcard patterns, compromising the integrity of log data in transit.

Affected Products

• One Identity syslog-ng versions prior to 4.8.2
• Debian Linux 11.0 (bullseye) syslog-ng packages
• Any downstream distribution shipping vulnerable syslog-ng builds

Discovery Timeline

• 2025-05-07 - CVE-2024-47619 published to NVD
• 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-47619

Vulnerability Analysis

The vulnerability resides in tls_wildcard_match() within lib/transport/tls-verifier.c. RFC 6125 restricts certificate wildcards to a single * in the left-most label of a DNS name. The syslog-ng implementation relied on glib pattern matching semantics, which are more permissive than the TLS naming specification. As a result, multi-label wildcards such as foo.*.bar and partial-label wildcards such as foo.a*c.bar were accepted as valid matches against the connection hostname.

This behavior undermines the host identity guarantee that TLS certificate verification is intended to provide. An attacker holding a certificate with an over-broad wildcard, whether obtained from a misconfigured certificate authority or an internal PKI, can satisfy syslog-ng's verification routine for hostnames it should not control. Log streams that carry sensitive operational, authentication, or audit data can then be intercepted or modified.

Root Cause

The root cause is reliance on g_pattern_match style globbing without enforcing TLS-specific wildcard constraints. The pre-patch code did not validate that the * character was confined to the left-most label or that it constituted the entire label, allowing non-compliant patterns to authenticate successfully.

Attack Vector

Exploitation requires network-adjacent positioning between a syslog-ng client and server, plus possession of a certificate chain trusted by the victim with a wildcard pattern such as foo.*.bar. The attacker terminates the TLS connection from the client and presents the over-broad certificate. The flawed matcher returns true for the target hostname, allowing the attacker to relay, drop, or tamper with log records.

/*
+ * Copyright (c) 2024 One Identity LLC.
+ * Copyright (c) 2024 Franco Fichtner
  * Copyright (c) 2002-2011 Balabit
  * Copyright (c) 1998-2011 Balázs Scheidler
  */

// New header export in lib/transport/tls-verifier.h
gboolean tls_verify_certificate_name(X509 *cert, const gchar *hostname);

gboolean tls_wildcard_match(const gchar *host_name, const gchar *pattern);

Source: syslog-ng commit dadfdbecde5bfe710b0a6ee5699f96926b3f9006. The patch refactors wildcard handling so that tls_wildcard_match() is isolated and enforces single-label, full-label wildcard semantics.

Detection Methods for CVE-2024-47619

Indicators of Compromise

• Syslog-ng peer certificates containing multi-label wildcards such as *.*.example.com or partial-label wildcards like foo.a*c.example.com.
• Unexpected TLS session resumptions or peer fingerprint changes on syslog-ng listeners and forwarders.
• Log gaps, reordering, or duplicate event IDs on receivers that previously had stable ingest rates.

Detection Strategies

• Inventory all syslog-ng installations and compare versions against the fixed release 4.8.2 using package managers or syslog-ng --version.
• Inspect trusted CA stores and per-connection certificates for non-RFC-6125-compliant wildcard patterns.
• Correlate syslog-ng connection events with network flow data to identify TLS handshakes from unexpected source IPs or ASNs.

Monitoring Recommendations

• Enable verbose TLS logging on syslog-ng (transport(tls(...)) with debug) to capture presented certificate subjects and SANs.
• Alert on changes in the issuer or subject of certificates terminating syslog-ng connections via SIEM correlation rules.
• Monitor debian-lts-announce and the syslog-ng GitHub security advisories for updates.

How to Mitigate CVE-2024-47619

Immediate Actions Required

• Upgrade syslog-ng to version 4.8.2 or later on all clients and servers participating in TLS log transport.
• For Debian systems, apply updates referenced in the Debian LTS announcement.
• Audit existing peer certificates and revoke any that use multi-label or partial-label wildcards.
• Restrict syslog-ng TLS endpoints to known client IP ranges using firewall rules until patching is complete.

Patch Information

The fix is delivered in syslog-ng release 4.8.2 via commit dadfdbecde5bfe710b0a6ee5699f96926b3f9006. The patch exposes tls_wildcard_match() as a discrete function and enforces wildcard placement rules consistent with RFC 6125. Distribution maintainers, including Debian LTS, have backported the change to supported branches.

Workarounds

• Pin syslog-ng peers using trusted-dn() or trusted-keys() instead of relying on hostname wildcard matching.
• Configure mutual TLS with certificates issued by a private CA that does not sign wildcard certificates.
• Terminate syslog-ng TLS at a reverse proxy that performs strict RFC 6125 hostname verification.

# Example: enforce explicit peer DN matching in syslog-ng.conf
destination d_remote {
    network(
        "logs.internal.example.com"
        transport("tls")
        port(6514)
        tls(
            ca-dir("/etc/syslog-ng/ca.d")
            peer-verify(required-trusted)
            trusted-dn("CN=logs.internal.example.com, O=Example Inc")
        )
    );
};