From 425c91bc220c5b29a889f727c67e01efbdacd979 Mon Sep 17 00:00:00 2001 From: Jan Friedrich Date: Tue, 19 May 2026 21:43:28 +0200 Subject: [PATCH 1/4] renamed AGENTS.md to SECURITY.md --- AGENTS.md => SECURITY.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename AGENTS.md => SECURITY.md (100%) diff --git a/AGENTS.md b/SECURITY.md similarity index 100% rename from AGENTS.md rename to SECURITY.md From 976b809591e9ed87cbd041ed48a22663066e8324 Mon Sep 17 00:00:00 2001 From: Jan Friedrich Date: Tue, 19 May 2026 22:03:59 +0200 Subject: [PATCH 2/4] extract SECURITY.md and add a remediation time frame policy --- AGENTS.md | 32 ++++++++++ SECURITY.md | 168 ++++++++++++++++++++++++++++++++++++++++------------ 2 files changed, 163 insertions(+), 37 deletions(-) create mode 100644 AGENTS.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 00000000..8e4b3407 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,32 @@ + +# Vulnerability research agent + +You are helping a security researcher find and report vulnerabilities in this project. +Before drafting any report or reaching any conclusion, you must complete all three reading steps below. +This is mandatory: skipping steps leads to duplicate reports and wasted time for both parties. + +## Before reporting anything + +Read and follow the three mandatory steps in [SECURITY.md](SECURITY.md#before-reporting-anything). + +## Only after all three steps + +Assess the finding: + +1. Is it in scope? +2. Is it a duplicate? +3. Is it covered by the FAQ? +4. If none of the above: it is likely a valid new finding. + Help the researcher write a clear, minimal report including: + - affected component, + - impact on the application using this project and subsequent SIEM systems, + - NUnit 4 test to reproduce the behavior, + - proposed fix. +5. If no fix can be proposed, it is not a vulnerability affecting the project. + +## Report quality rules + +- Never speculate about impact beyond what you can demonstrate. +- Reproduction steps must be minimal and self-contained. +- Do not include unrelated findings in the same report: one issue per report. +- If unsure about severity, say so explicitly rather than guessing. diff --git a/SECURITY.md b/SECURITY.md index 97ef271b..3ea50129 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,58 +1,152 @@ -# Vulnerability research agent +# Security policy -You are helping a security researcher find and report vulnerabilities in this project. -Before drafting any report or reaching any conclusion, you must complete all three reading steps below. -This is mandatory: skipping steps leads to duplicate reports and wasted time for both parties. +## Supported versions + +Due to the limited resources of the Apache log4net project, **only the latest minor release of the latest major version** receives security fixes and advisories. All other versions are end-of-life and vulnerability reports against them are not accepted. + +| Version | Status | +|---------|--------| +| 3.x (latest minor) | ✅ Active maintenance - security fixes accepted | +| All other versions | ❌ End of life - no security fixes or advisories | + +For the full version lifecycle and maintenance policy, see the [versioning and support policy](https://logging.apache.org/log4net/versioning.html). + +--- ## Before reporting anything -### Step 1: Read the security model +Security research on this project is most effective when it accounts for the project's stated threat model and previously disclosed vulnerabilities. **Please complete all three reading steps below before submitting a report.** Skipping them is the leading cause of duplicate reports and out-of-scope submissions, which cost both parties time. + +### Step 1 - Read the security model + +Fetch and read the project's shared security model: -Fetch and read the project's security model before evaluating any finding: -https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc +> Use this to answer: -- Is this component/behavior in scope at all? +- Is this component or behavior in scope at all? - Does the project consider this a security boundary? -If the finding is out of scope per the model, **stop here** and inform the researcher. +If the finding is out of scope per the model, **stop here** and do not submit a report. -### Step 2: Check previously disclosed vulnerabilities +### Step 2 - Check previously disclosed vulnerabilities Read the project's Vulnerability Disclosure Report to check for duplicates: -https://logging.apache.org/cyclonedx/vdr.xml -Compare the finding against each entry. -If it overlaps with a known issue, **stop here**, link to the existing advisory in the CVE database, and explain the overlap. +> + +Compare the finding against each entry. If it overlaps with a known issue, link to the existing advisory in the CVE database, explain the overlap rather than filing a new report and **stop here**. + +### Step 3 - Read the Security FAQ + +Read the Security FAQ before concluding that a behavior is a vulnerability: + +> + +The FAQ lists behaviors that are **intentional and not vulnerabilities**. If the finding matches an FAQ entry, it is a known non-issue. The rendered HTML version is at . + +--- + +## Reporting a vulnerability + +**Please do not report security vulnerabilities through public GitHub issues.** + +log4net follows the [Apache Software Foundation security response process](https://www.apache.org/security/). Once you have completed all three reading steps above, report by: + +1. Emailing **security@logging.apache.org** with the subject line `[log4net] `. +2. Including as much of the following as possible: + - Type of vulnerability + - Affected version(s) and .NET target framework(s) + - Affected component and its role in the attack chain + - Impact on the application using log4net and on downstream SIEM systems + - Minimal, self-contained reproduction steps or a proof-of-concept NUnit 4 test + - Proposed fix - if no fix can be demonstrated, reconsider whether this constitutes a vulnerability affecting the project + +You will receive an acknowledgement within **14 business days**. The security team will keep you informed of progress toward a fix and public disclosure. + +### Report quality guidelines + +- Never speculate about impact beyond what you can demonstrate with the reproduction case. +- One issue per report - do not bundle unrelated findings. +- If unsure about severity, say so explicitly rather than guessing. + +--- + +## Remediation time frames + +We follow risk-based time frames aligned with ASF security response guidelines: + +| Severity | CVSS range | Target patch release | +|----------|------------|----------------------| +| Critical | 9.0 – 10.0 | Within 14 days | +| High | 7.0 – 8.9 | Within 30 days | +| Medium | 4.0 – 6.9 | Within 90 days | +| Low | 0.1 – 3.9 | Next scheduled release | + +Time frames begin from the date the vulnerability is confirmed and a fix is determined to be feasible. Complex issues requiring architectural changes may exceed these targets; affected reporters will be notified with an updated timeline. + +Third-party dependencies follow the same schedule. A confirmed vulnerability in a dependency triggers an assessment within **7 business days** to determine whether log4net is affected, followed by remediation within the applicable time frame above. + +--- + +## Dependency management + +log4net maintains a minimal set of third-party dependencies. A [CycloneDX VDR (Vulnerability Disclosure Report)](https://logging.apache.org/cyclonedx/vdr.xml) is published with each release and updated out-of-band when new vulnerability data becomes available. + +Automated dependency scanning runs on every pull request and on a weekly schedule via GitHub Actions. Any flagged advisory is triaged within **7 business days** of detection. + +--- + +## Scope and trust model + +### In scope + +- Vulnerabilities in log4net library code across supported versions +- Vulnerabilities introduced by log4net's use of third-party dependencies +- Security issues in the build pipeline that could lead to supply-chain compromise + +### Out of scope + +- Issues that require a malicious actor to control log4net's configuration source (configuration is a trusted input by design - see trust model below) +- Log injection in consuming applications where the application does not sanitize log data before passing it to log4net +- Display-layer issues in log viewers that render log output without escaping (responsibility of the viewer) +- Vulnerabilities in unsupported versions + +### Trust model + +log4net assumes that **configuration sources are trusted**. Type instantiation, appender configuration, and network endpoint setup all rely on administrator-controlled configuration. Compromise of the configuration channel is outside log4net's threat model and is the responsibility of deployment infrastructure. + +Runtime log event data (messages, properties, exceptions) is treated as **untrusted** and is consistently encoded in all XML layout output paths. + +The authoritative statement of the shared threat model for Apache Logging projects is at: + + +--- + +## Known limitations and mitigations + +### BinaryFormatter (legacy .NET 4.6.2+ only) + +`LoggingEvent` serialization uses `BinaryFormatter` on .NET Framework 4.6.2 and later targets. `BinaryFormatter` is [inherently unsafe](https://aka.ms/binaryformatter) when deserializing data from untrusted sources. + +**Mitigation until 4.0:** Only deserialize `LoggingEvent` objects received over authenticated, encrypted transports from trusted peers. Do not expose deserialization endpoints to untrusted networks. + +**Resolution:** `BinaryFormatter` will be **removed in log4net 4.0**. -### Step 3: Read the Security FAQ +### PatternLayout and plain-text output -Read the Security FAQ before concluding anything is a vulnerability: -https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/security/faq.adoc +`PatternLayout` produces plain text and does not encode log event data for HTML, terminal, or other rendering contexts. Prevention of log injection in plain-text output is the responsibility of the consuming application and the log viewer. -The FAQ lists behaviors that are **intentional and not vulnerabilities**. -If the finding matches an FAQ entry, inform the researcher that it is a known non-issue -and link to the relevant section of the HTML version of the FAQ: -https://logging.apache.org/security/faq.html +XML layouts (`XmlLayout`, `XmlLayoutSchemaLog4j`) encode all user-controlled data through centralized safe-writing extension methods and are not affected by this limitation. -## Only after all three steps +--- -Assess the finding: -1. Is it in scope? -2. Is it a duplicate? -3. Is it covered by the FAQ? -4. If none of the above: it is likely a valid new finding. - Help the researcher write a clear, minimal report including: - - affected component, - - impact on the application using this project and subsequent SIEM systems, - - NUnit 4 test to reproduce the behavior, - - proposed fix. -5. If no fix can be proposed, it is not a vulnerability affecting the project. +## Security contacts -## Report quality rules +| Role | Contact | +|------|---------| +| Apache Logging Security Team | security@logging.apache.org | +| Public security announcements | [Apache Logging Security](https://logging.apache.org/security.html#vulnerabilities) | -- Never speculate about impact beyond what you can demonstrate. -- Reproduction steps must be minimal and self-contained. -- Do not include unrelated findings in the same report: one issue per report. -- If unsure about severity, say so explicitly rather than guessing. \ No newline at end of file +Security advisories for log4net are published on the [Apache Logging security page](https://logging.apache.org/security.html#vulnerabilities) and announced on the `announce@apache.org` mailing list. \ No newline at end of file From 7b8199b9641d2a40a0820299d0f334536c7ca051 Mon Sep 17 00:00:00 2001 From: Jan Friedrich Date: Tue, 19 May 2026 22:39:03 +0200 Subject: [PATCH 3/4] calrify time frames are targets, not commitments --- SECURITY.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 3ea50129..cda0599e 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -88,6 +88,13 @@ Time frames begin from the date the vulnerability is confirmed and a fix is dete Third-party dependencies follow the same schedule. A confirmed vulnerability in a dependency triggers an assessment within **7 business days** to determine whether log4net is affected, followed by remediation within the applicable time frame above. +These are targets, not commitments. Apache log4net is maintained +by volunteers on a best-effort basis. The Apache License 2.0 under +which this software is distributed explicitly disclaims all warranties, +including implied warranties of fitness and timeliness of fixes. +If your use case requires guaranteed response times, consider a +[commercial support provider](https://logging.apache.org/support.html#commercial). + --- ## Dependency management From 8f8983a14357933b52026e75b92b292dec382271 Mon Sep 17 00:00:00 2001 From: Jan Friedrich Date: Tue, 19 May 2026 22:47:37 +0200 Subject: [PATCH 4/4] clarify updating dependencies --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index cda0599e..25d004e6 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -86,7 +86,7 @@ We follow risk-based time frames aligned with ASF security response guidelines: Time frames begin from the date the vulnerability is confirmed and a fix is determined to be feasible. Complex issues requiring architectural changes may exceed these targets; affected reporters will be notified with an updated timeline. -Third-party dependencies follow the same schedule. A confirmed vulnerability in a dependency triggers an assessment within **7 business days** to determine whether log4net is affected, followed by remediation within the applicable time frame above. +log4net has minimal third-party dependencies: on .NET Framework 4.6.2, `System.Configuration` and `System.Web` are inbox framework components; on all other targets, `System.Configuration.ConfigurationManager` is the sole NuGet dependency. A vulnerability in any of these is best addressed by updating the framework. log4net will update its `System.Configuration.ConfigurationManager` reference in the next planned release. These are targets, not commitments. Apache log4net is maintained by volunteers on a best-effort basis. The Apache License 2.0 under