CVE-2018-1285: XXE in Apache log4net

Apache log4net is one of the most widely deployed logging libraries in the .NET ecosystem, embedded deep inside enterprise applications, internal tooling, and third-party components that many organizations don't even know they depend on. CVE-2018-1285 is an XML External Entity (XXE) injection vulnerability in log4net's configuration parser: versions of log4net prior to 2.0.10 fail to disable external entity resolution when loading XML configuration data, which means an attacker who can influence or supply a log4net configuration file can potentially read local files, trigger outbound network requests from the host, or cause a denial of service. Given how quietly logging libraries get pulled into build pipelines and how rarely they get revisited once "working," this is exactly the kind of transitive dependency risk that tends to survive in production for years after a fix ships.

What the vulnerability actually does

log4net supports configuring loggers, appenders, and layouts through an XML configuration file (commonly log4net.config or an XML block embedded in App.config/Web.config). The library's configuration classes — the code path exercised by XmlConfigurator and related helpers in the log4net.Config namespace — parsed this XML using standard .NET XML APIs without explicitly disabling DTD processing and external entity resolution.

XML's DTD (Document Type Definition) feature allows a document to declare custom entities, including entities that reference external resources by URI:

<?xml version="1.0"?>
<!DOCTYPE log4net [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<log4net>
  <appender name="X">
    <file value="&xxe;"/>
  </appender>
</log4net>

When a parser resolves that SYSTEM entity, it can read arbitrary local files, request internal or external URLs (a classic vector for SSRF against cloud metadata endpoints and internal services), or, in the case of maliciously crafted recursive entities, exhaust memory or CPU (a "billion laughs"-style denial of service). Because log4net's parser did not prohibit DTD processing or lock down the XmlResolver, any code path that let an attacker influence the contents of a log4net configuration file — a misconfigured upload feature, a shared configuration store, a multi-tenant environment where configuration is user-suppliable, or a supply-chain scenario where a malicious package ships a poisoned config — could be turned into an XXE primitive.

It's worth being precise about the practical exploitability: the realistic exposure for CVE-2018-1285 in most deployments is scenarios where an attacker has some ability to write or modify the log4net configuration input (for example, applications that let users upload or select configuration files, or systems that load configuration from an untrusted or shared source). It is not a remote, unauthenticated "send one packet and own the box" bug — the severity comes from what happens if an attacker can reach that configuration parsing path, which is a more common condition in enterprise .NET environments than it first appears, especially in multi-tenant SaaS platforms and admin consoles that expose logging configuration to operators.

Affected versions and components

• Affected: Apache log4net releases prior to 2.0.10.
• Fixed in: log4net 2.0.10, which addresses the issue by hardening the XML parsing configuration used when loading log4net configuration data (disabling external entity/DTD resolution consistent with Microsoft's standard XXE-prevention guidance for .NET's XmlDocument/XmlReader APIs).
• Component: The vulnerable code lives in log4net.dll, specifically in the configuration-loading path (log4net.Config.XmlConfigurator and related configurator classes) that parses the XML configuration file at startup or on demand.
• Affected platforms: Any .NET application (Framework or, for later log4net releases, .NET Core/.NET) that references a pre-2.0.10 log4net package and loads configuration from XML.

Because log4net is frequently pulled in transitively — through internal shared libraries, vendor components, or older application scaffolding that hasn't been touched since it was written — the affected footprint in a typical enterprise .NET estate is often larger than what shows up in a direct top-level dependency scan.

CVSS, EPSS, and KEV context

CVE-2018-1285 was assessed by NVD as a network-exploitable, low-complexity issue with a confidentiality impact, consistent with the general XXE pattern (an attacker who can influence the input can potentially disclose local file contents or make the server issue outbound requests, without directly compromising integrity or availability). We'd rather not restate a precise CVSS decimal here without citing the current NVD record directly, since NVD scoring metadata can be revised after initial publication — check the live NVD/CVE entry for the current authoritative score before using it in a risk report.

On exploitation signals: this CVE has not been observed in widespread, opportunistic exploitation campaigns, and it does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing. That doesn't make it safe to ignore — XXE bugs are commonly chained with other weaknesses (an SSRF-adjacent upload feature, a misconfigured multi-tenant config store, an internal admin tool) precisely because they're easy to overlook in dependency inventories. Low observed in-the-wild exploitation for an eight-year-old library bug mostly reflects that log4net configuration isn't typically internet-facing by default — not that the underlying flaw is benign wherever attacker-controlled configuration input does reach it.

Timeline

• Disclosure: CVE-2018-1285 was publicly disclosed and assigned in 2018, alongside the release of the fixed version.
• Fix released: Apache log4net 2.0.10 shipped with the corrected XML parsing behavior.
• Since then: The CVE has remained a standard entry in dependency vulnerability databases and SCA (software composition analysis) tooling; because log4net has a long tail of legacy adopters in enterprise .NET codebases, pre-2.0.10 references still surface regularly in modern software composition analysis and SBOM audits, years after the fix shipped.

Remediation steps

1. Upgrade log4net to 2.0.10 or later. This is the definitive fix — it's a drop-in NuGet package update for most applications and doesn't require configuration schema changes.
2. Inventory transitive references, not just direct ones. Run a software composition analysis (SCA) scan or inspect your dependency lockfiles/packages.config for log4net brought in indirectly through internal libraries, vendor SDKs, or older shared components. A direct dotnet list package or NuGet reference check at the top level will miss transitive copies.
3. Audit how your log4net configuration is sourced. If configuration XML is ever read from a location that isn't fully trusted — user uploads, shared network paths, multi-tenant config stores, values fetched from an external system — treat that as a priority upgrade path even if you can't patch everything immediately.
4. Apply defense-in-depth XML hardening regardless of the library. If you maintain custom code that also parses XML (config files, SOAP payloads, import/export features), explicitly disable DTD processing and external entity resolution — set XmlResolver to null on XmlDocument, or use XmlReaderSettings with DtdProcessing.Prohibit and XmlResolver = null — as a general practice, not just for log4net's own configuration loader.
5. Re-scan after remediation. Confirm the upgraded package version is actually resolved at build and runtime (watch for pinned versions, vendored copies, or build caches that silently keep serving the old assembly).
6. Restrict blast radius where full remediation is delayed. Network egress controls that block outbound requests from application hosts to unexpected destinations, and file-system permissions that limit what a service account can read, reduce the practical impact of an XXE primitive even before the patch lands.

How Safeguard Helps

CVE-2018-1285 is a textbook case for why software supply chain visibility has to go deeper than a top-level package.json or .csproj scan. Safeguard continuously inventories every dependency in your software supply chain — direct and transitive — and maps them against known CVEs like this one, so a stale copy of log4net buried three layers deep in a vendor SDK doesn't sit invisible in production for years.

Specifically, Safeguard helps teams operationalize the remediation above:

• Full-depth SBOM generation that surfaces transitive references to vulnerable log4net versions, including copies pulled in through internal shared libraries or third-party components your team didn't write.
• Continuous CVE monitoring that flags CVE-2018-1285 (and similar XXE/deserialization-class issues) the moment a vulnerable version enters your build or artifact registry, rather than relying on periodic point-in-time scans.
• Prioritized risk scoring that accounts for real reachability — distinguishing a log4net reference sitting in dead code from one that's wired into a configuration path an attacker can actually influence — so security teams spend remediation effort where it matters instead of chasing every match in a raw CVE feed.
• Provenance and build integrity checks that verify the log4net package (and everything else in your build) came from an expected, unmodified source, closing off the kind of supply-chain tampering scenario where a malicious actor swaps in a poisoned configuration or dependency upstream of your build.
• Policy gates in CI/CD that block builds from shipping with known-vulnerable versions of log4net or any other dependency past your organization's patch SLA, turning "we should really update that" into an enforced control instead of a backlog item.

Legacy vulnerabilities like CVE-2018-1285 rarely disappear on their own — they linger in forgotten internal libraries and unmaintained services until an audit, an incident, or a customer questionnaire forces the issue. Safeguard is built to surface that risk continuously, before it becomes any of those three.