Common Weakness Enumeration

CWE-117

Allowed

Improper Output Neutralization for Logs

Abstraction: Base · Status: Draft

The product constructs a log message from external input, but it does not neutralize or incorrectly neutralizes special elements when the message is written to a log file.

237 vulnerabilities reference this CWE, most recent first.

GHSA-P56W-H56Q-C97X

Vulnerability from github – Published: 2023-11-08 00:30 – Updated: 2023-11-15 15:30

Details

YugabyteDB is vulnerable to cross site scripting (XSS) via log injection. Writing invalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.

Severity

7.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-6002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-08T00:15:08Z",
    "severity": "HIGH"
  },
  "details": "YugabyteDB is vulnerable to cross site scripting (XSS) via log injection.\u00a0Writing invalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.\n",
  "id": "GHSA-p56w-h56q-c97x",
  "modified": "2023-11-15T15:30:20Z",
  "published": "2023-11-08T00:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6002"
    },
    {
      "type": "WEB",
      "url": "https://www.yugabyte.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PFXF-WH96-FVJC

Vulnerability from github – Published: 2020-06-25 20:02 – Updated: 2021-01-07 23:50

Summary

Log Forging in generator-jhipster-kotlin

Details

Impact

We log the mail for invalid password reset attempts. As the email is provided by a user and the api is public this can be used by an attacker to forge log entries. This is vulnerable to https://cwe.mitre.org/data/definitions/117.html

This problem affects only application generated with jwt or session authentication. Applications using oauth are not vulnerable.

Patches

version 1.7.0.

Workarounds

In AccountResource.kt you should change the line

 log.warn("Password reset requested for non existing mail '$mail'");

 log.warn("Password reset requested for non existing mail");

References

https://cwe.mitre.org/data/definitions/117.html
https://owasp.org/www-community/attacks/Log_Injection
https://www.baeldung.com/jvm-log-forging

For more information

If you have any questions or comments about this advisory: * Open an issue in jhipster kotlin

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "generator-jhipster-kotlin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.6.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2020-4072"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-25T20:02:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWe log the mail for invalid password reset attempts. \nAs the email is provided by a user and the api is public this can be used by an attacker to forge log entries.\nThis is vulnerable to https://cwe.mitre.org/data/definitions/117.html\n\nThis problem affects only application generated with jwt or session authentication. Applications using oauth are not vulnerable.\n\n### Patches\n\nversion 1.7.0.\n\n### Workarounds\n\nIn `AccountResource.kt` you should change the line\n\n```kotlin\n log.warn(\"Password reset requested for non existing mail \u0027$mail\u0027\");\n```\n\nto \n\n```kotlin\n log.warn(\"Password reset requested for non existing mail\");\n```\n\n### References\n\n* https://cwe.mitre.org/data/definitions/117.html\n* https://owasp.org/www-community/attacks/Log_Injection\n* https://www.baeldung.com/jvm-log-forging\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [jhipster kotlin](https://github.com/jhipster/jhipster-kotlin)",
  "id": "GHSA-pfxf-wh96-fvjc",
  "modified": "2021-01-07T23:50:00Z",
  "published": "2020-06-25T20:02:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jhipster/jhipster-kotlin/security/advisories/GHSA-pfxf-wh96-fvjc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4072"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jhipster/jhipster-kotlin/commit/426ccab85e7e0da562643200637b99b6a2a99449"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-community/attacks/Log_Injection"
    },
    {
      "type": "WEB",
      "url": "https://www.baeldung.com/jvm-log-forging"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Log Forging in generator-jhipster-kotlin"
}

GHSA-PM48-CVV2-29Q5

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2024-09-09 21:12

Summary

Ansible Uses Plugins That Disclose Credentials

Details

Ansible, all ansible_engine-2.x versions and ansible_engine-3.x up to ansible_engine-3.5, was logging at the DEBUG level which lead to a disclosure of credentials if a plugin used a library that logged credentials at the DEBUG level. This flaw does not affect Ansible modules, as those are executed in a separate process.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

8.5 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0a1"
            },
            {
              "fixed": "2.7.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0a1"
            },
            {
              "fixed": "2.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-14846"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-17T22:21:08Z",
    "nvd_published_at": "2019-10-08T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Ansible, all ansible_engine-2.x versions and ansible_engine-3.x up to ansible_engine-3.5, was logging at the DEBUG level which lead to a disclosure of credentials if a plugin used a library that logged credentials at the DEBUG level. This flaw does not affect Ansible modules, as those are executed in a separate process.",
  "id": "GHSA-pm48-cvv2-29q5",
  "modified": "2024-09-09T21:12:08Z",
  "published": "2022-05-24T16:58:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14846"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/pull/63366"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/90e74dd2600e5cc42dd9b4f4656f3d651c4ce5c4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/cb0f535a8b254a2daf69cd067e842fabb2993034"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/d961f676c01023a6a21503df16ba551a550e515b"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3201"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3202"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3203"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3207"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0756"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14846"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ansible/ansible"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/ansible/PYSEC-2019-4.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/05/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/01/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4950"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ansible Uses Plugins That Disclose Credentials"
}

GHSA-PR3P-HV9Q-44XX

Vulnerability from github – Published: 2023-07-11 03:30 – Updated: 2024-04-04 05:54

Details

While using a specific function, SAP ERP Defense Forces and Public Security - versions 600, 603, 604, 605, 616, 617, 618, 802, 803, 804, 805, 806, 807, allows an authenticated attacker with admin privileges to write arbitrary data to the syslog file. On successful exploitation, an attacker could modify all the syslog data causing a complete compromise of integrity of the application.

Severity

4.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-36924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-11T03:15:10Z",
    "severity": "MODERATE"
  },
  "details": "While using a specific function, SAP ERP Defense Forces and Public Security - versions 600, 603, 604, 605, 616, 617, 618, 802, 803, 804, 805, 806, 807, allows an authenticated attacker with admin privileges to write arbitrary data to the syslog file. On successful exploitation, an attacker could modify all the syslog data causing a complete compromise of integrity of the application.\n\n",
  "id": "GHSA-pr3p-hv9q-44xx",
  "modified": "2024-04-04T05:54:45Z",
  "published": "2023-07-11T03:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36924"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3351410"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PRPW-WWV7-XJJR

Vulnerability from github – Published: 2026-10-06 20:37 – Updated: 2026-10-06 20:37

Summary

Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields

Details

Root Cause

File: internal/auditlog/formats.go — multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping \r or \n:

// Part B — request headers (lines 72–80)
for k, vv := range al.Transaction().Request().Headers() {
    for _, v := range vv {
        res.WriteByte('\n')
        res.WriteString(k)
        res.WriteString(": ")
        res.WriteString(v)   // ← raw
    }
}

// Part C — request body (lines 85–86)
if body := al.Transaction().Request().Body(); body != "" {
    res.WriteString(body)    // ← raw
    res.WriteByte('\n')
}

// Part E — response body (lines 93–94)      raw
// Part F — response headers (lines 111–118) raw
// Part H — error messages (line 125)        raw
// Part K — matched-rule raw data (line 151)  raw

The Native format's section structure is line-based: sections are delimited by lines of the form --<10-char-random-prefix>-<Part>--, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing \n break the structural invariant and allow the attacker to inject lines that look like genuine audit content.

The other two Native-format implementations in Coraza are not affected: the JSON formatter (formats_json.go) and the OCSF formatter both round-trip values through json.Marshal, which escapes \r and \n.

Impact

An attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines — including lines that visually resemble new log entries — into the audit log file of a defender running the default SecAuditLogFormat Native configuration. Realistic consequences:

Forging entries to shift attribution. An injected line such as [client "9.9.9.9"] Coraza: Warning. ... sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart.
Confusing SIEM correlation. Any ingestion pipeline that splits on --...-[A-Z]-- boundaries or on [client "..."] patterns without validating the session prefix will treat the forged lines as separate records.
Breaking log-parsing tooling. Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences.
Hiding genuine incidents. An attacker who can also trigger a rule match on the same transaction (trivial — send any request that matches any audit-logged rule) can bury the real match under noise they control.

The forged lines cannot trivially impersonate an entire separate session: the 10-char random prefix in the real boundaries (boundaryPrefix := "--" + utils.RandomString(10) + "-", line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a single record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks.

Proof of Concept

Server with coraza.conf-recommended-style defaults:

SecRuleEngine On
SecAuditEngine On
SecAuditLogParts ABCFHZ
SecAuditLogType Serial
SecAuditLog /tmp/audit.log
SecAuditLogFormat Native
SecRequestBodyAccess On
SecRule REQUEST_METHOD "@rx ." \
    "id:1001,phase:1,pass,log,auditlog,msg:'trigger'"

Body vector — reachable via stock `coraza/v3/http` + `net/http`

Send an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries:

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded

evil=benign\r\n--coraza-forged-X--\r\nForgedLine: yes\r\n--coraza-forged-H--\r\n[client "9.9.9.9"] FAKE ATTACK ENTRY

Resulting audit.log:

--heLNtylvjY-C--
evil=benign
--coraza-forged-X--
ForgedLine: yes
--coraza-forged-H--
[client "9.9.9.9"] FAKE ATTACK ENTRY

--heLNtylvjY-F--

The forged --coraza-forged-X-- / --coraza-forged-H-- boundaries and the spoofed [client "9.9.9.9"] line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no error is raised, the attack is invisible to the WAF.

Header vector — reachable via non-net/http integrations only

The same effect applies to Part B (request headers) and Part F (response headers) when a header value contains raw \r\n. Go's net/http rejects such headers at parse time (400 Bad Request), so the stock HTTP wrapper is safe from this path; the vector is reachable when Coraza is called with header values that were not validated by net/http:

coraza-spoa (HAProxy SPOP agent) forwards headers from HAProxy, which has more permissive validation.
coraza-proxy-wasm / Envoy WASM hosts forward header values from the upstream proxy.
Custom FFI/WASM hosts and any embedder calling tx.AddRequestHeader(k, v) with unvalidated bytes.

Other raw-write sites (Part E response body, Part H error messages, Part K matched-rule data) share the same class of issue and should be fixed together.

Mitigation

Escape \r and \n at every raw-write site in internal/auditlog/formats.go. A single package-level helper is sufficient:

var logEscaper = strings.NewReplacer("\r", "\\r", "\n", "\\n")

// Part B — header values:
res.WriteString(logEscaper.Replace(v))

// Part F — header values: same
// Part H — error messages:
res.WriteString(logEscaper.Replace(alWithErrMsg.ErrorMessage()))
// Part K — matched-rule raw data:
res.WriteString(logEscaper.Replace(alEntry.Data().Raw()))

For Part C / Part E (bodies), the choice is policy-dependent:

Escape inline (logEscaper.Replace(body)): keeps the log human-readable for text bodies but loses fidelity for binary.
Base64 / hex-encode the whole part: binary-safe, matches the spirit of ModSecurity v2's binary-log handling, but less human-readable.

Escaping is the minimum; base64 for bodies is the more conservative default and is a reasonable audit-log-default change.

Additional defensive measure

Consider lengthening the boundaryPrefix random suffix from 10 chars to ≥16 chars (line 42). This strictly raises the bar for attackers attempting to fully forge a separate-looking session (not just inject lines into the current one). Low-cost change; narrows future variants of this bug class.

Affected versions

The Native formatter has been present since v3.0.0 (file existed at the first-release commit). All releases >= 3.0.0, <= 3.7.0 are affected when SecAuditLogFormat Native is used with SecAuditLogType Serial or SecAuditLogType Concurrent.

Unaffected:

Deployments using SecAuditLogFormat JSON (formats_json.go uses json.Marshal which escapes \r\n).
Deployments using OCSF output.
Deployments with SecAuditEngine Off.

References

internal/auditlog/formats.go lines 42, 72–80 (Part B), 85–88 (Part C), 93–96 (Part E), 111–118 (Part F), 125 (Part H), 151 (Part K)
coraza.conf-recommended — default SecAuditLogFormat Native, SecAuditLogParts ABIJDEFHZ / ABCFHZ variants
CWE-117 — Improper Output Neutralization for Logs
CWE-93 — CRLF Injection

Severity

5.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T20:37:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Root Cause\n\nFile: `internal/auditlog/formats.go` \u2014 multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping `\\r` or `\\n`:\n\n```go\n// Part B \u2014 request headers (lines 72\u201380)\nfor k, vv := range al.Transaction().Request().Headers() {\n    for _, v := range vv {\n        res.WriteByte(\u0027\\n\u0027)\n        res.WriteString(k)\n        res.WriteString(\": \")\n        res.WriteString(v)   // \u2190 raw\n    }\n}\n\n// Part C \u2014 request body (lines 85\u201386)\nif body := al.Transaction().Request().Body(); body != \"\" {\n    res.WriteString(body)    // \u2190 raw\n    res.WriteByte(\u0027\\n\u0027)\n}\n\n// Part E \u2014 response body (lines 93\u201394)      raw\n// Part F \u2014 response headers (lines 111\u2013118) raw\n// Part H \u2014 error messages (line 125)        raw\n// Part K \u2014 matched-rule raw data (line 151)  raw\n```\n\nThe Native format\u0027s section structure is line-based: sections are delimited by lines of the form `--\u003c10-char-random-prefix\u003e-\u003cPart\u003e--`, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing `\\n` break the structural invariant and allow the attacker to inject lines that look like genuine audit content.\n\nThe other two Native-format implementations in Coraza are not affected: the JSON formatter (`formats_json.go`) and the OCSF formatter both round-trip values through `json.Marshal`, which escapes `\\r` and `\\n`.\n\n## Impact\n\nAn attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines \u2014 including lines that visually resemble new log entries \u2014 into the audit log file of a defender running the default `SecAuditLogFormat Native` configuration. Realistic consequences:\n\n- **Forging entries to shift attribution.** An injected line such as `[client \"9.9.9.9\"] Coraza: Warning. ...` sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart.\n- **Confusing SIEM correlation.** Any ingestion pipeline that splits on `--...-[A-Z]--` boundaries or on `[client \"...\"]` patterns without validating the session prefix will treat the forged lines as separate records.\n- **Breaking log-parsing tooling.** Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences.\n- **Hiding genuine incidents.** An attacker who can also trigger a rule match on the same transaction (trivial \u2014 send any request that matches *any* audit-logged rule) can bury the real match under noise they control.\n\nThe forged lines cannot trivially impersonate an entire *separate* session: the 10-char random prefix in the real boundaries (`boundaryPrefix := \"--\" + utils.RandomString(10) + \"-\"`, line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a *single* record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks.\n\n## Proof of Concept\n\nServer with `coraza.conf-recommended`-style defaults:\n\n```conf\nSecRuleEngine On\nSecAuditEngine On\nSecAuditLogParts ABCFHZ\nSecAuditLogType Serial\nSecAuditLog /tmp/audit.log\nSecAuditLogFormat Native\nSecRequestBodyAccess On\nSecRule REQUEST_METHOD \"@rx .\" \\\n    \"id:1001,phase:1,pass,log,auditlog,msg:\u0027trigger\u0027\"\n```\n\n### Body vector \u2014 reachable via stock `coraza/v3/http` + `net/http`\n\nSend an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries:\n\n```\nPOST / HTTP/1.1\nContent-Type: application/x-www-form-urlencoded\n\nevil=benign\\r\\n--coraza-forged-X--\\r\\nForgedLine: yes\\r\\n--coraza-forged-H--\\r\\n[client \"9.9.9.9\"] FAKE ATTACK ENTRY\n```\n\nResulting audit.log:\n\n```\n--heLNtylvjY-C--\nevil=benign\n--coraza-forged-X--\nForgedLine: yes\n--coraza-forged-H--\n[client \"9.9.9.9\"] FAKE ATTACK ENTRY\n\n--heLNtylvjY-F--\n```\n\nThe forged `--coraza-forged-X--` / `--coraza-forged-H--` boundaries and the spoofed `[client \"9.9.9.9\"]` line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no error is raised, the attack is invisible to the WAF.\n\n### Header vector \u2014 reachable via non-net/http integrations only\n\nThe same effect applies to Part B (request headers) and Part F (response headers) when a header value contains raw `\\r\\n`. Go\u0027s `net/http` rejects such headers at parse time (`400 Bad Request`), so the stock HTTP wrapper is safe from this path; the vector is reachable when Coraza is called with header values that were not validated by `net/http`:\n\n- `coraza-spoa` (HAProxy SPOP agent) forwards headers from HAProxy, which has more permissive validation.\n- `coraza-proxy-wasm` / Envoy WASM hosts forward header values from the upstream proxy.\n- Custom FFI/WASM hosts and any embedder calling `tx.AddRequestHeader(k, v)` with unvalidated bytes.\n\nOther raw-write sites (Part E response body, Part H error messages, Part K matched-rule data) share the same class of issue and should be fixed together.\n\n## Mitigation\n\nEscape `\\r` and `\\n` at every raw-write site in `internal/auditlog/formats.go`. A single package-level helper is sufficient:\n\n```go\nvar logEscaper = strings.NewReplacer(\"\\r\", \"\\\\r\", \"\\n\", \"\\\\n\")\n\n// Part B \u2014 header values:\nres.WriteString(logEscaper.Replace(v))\n\n// Part F \u2014 header values: same\n// Part H \u2014 error messages:\nres.WriteString(logEscaper.Replace(alWithErrMsg.ErrorMessage()))\n// Part K \u2014 matched-rule raw data:\nres.WriteString(logEscaper.Replace(alEntry.Data().Raw()))\n```\n\nFor Part C / Part E (bodies), the choice is policy-dependent:\n\n- **Escape inline** (`logEscaper.Replace(body)`): keeps the log human-readable for text bodies but loses fidelity for binary.\n- **Base64 / hex-encode** the whole part: binary-safe, matches the spirit of ModSecurity v2\u0027s binary-log handling, but less human-readable.\n\nEscaping is the minimum; base64 for bodies is the more conservative default and is a reasonable audit-log-default change.\n\n### Additional defensive measure\n\nConsider lengthening the `boundaryPrefix` random suffix from 10 chars to \u226516 chars (line 42). This strictly raises the bar for attackers attempting to *fully* forge a separate-looking session (not just inject lines into the current one). Low-cost change; narrows future variants of this bug class.\n\n## Affected versions\n\nThe Native formatter has been present since `v3.0.0` (file existed at the first-release commit). All releases `\u003e= 3.0.0, \u003c= 3.7.0` are affected when `SecAuditLogFormat Native` is used with `SecAuditLogType Serial` or `SecAuditLogType Concurrent`.\n\n**Unaffected:**\n\n- Deployments using `SecAuditLogFormat JSON` (`formats_json.go` uses `json.Marshal` which escapes `\\r\\n`).\n- Deployments using OCSF output.\n- Deployments with `SecAuditEngine Off`.\n\n## References\n\n- `internal/auditlog/formats.go` lines 42, 72\u201380 (Part B), 85\u201388 (Part C), 93\u201396 (Part E), 111\u2013118 (Part F), 125 (Part H), 151 (Part K)\n- `coraza.conf-recommended` \u2014 default `SecAuditLogFormat Native`, `SecAuditLogParts ABIJDEFHZ` / `ABCFHZ` variants\n- CWE-117 \u2014 Improper Output Neutralization for Logs\n- CWE-93 \u2014 CRLF Injection",
  "id": "GHSA-prpw-wwv7-xjjr",
  "modified": "2026-10-06T20:37:27Z",
  "published": "2026-10-06T20:37:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-prpw-wwv7-xjjr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/a3079325547c7c1e08522aed4d6468f25d080e25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields"
}

GHSA-Q3Q9-Q5C6-HXFQ

Vulnerability from github – Published: 2026-09-03 21:31 – Updated: 2026-09-03 21:31

Details

IBM Netezza Software 11.3.0.3 through Interim Fix 002 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-9736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T21:17:24Z",
    "severity": "MODERATE"
  },
  "details": "IBM Netezza Software 11.3.0.3 through Interim Fix 002 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.",
  "id": "GHSA-q3q9-q5c6-hxfq",
  "modified": "2026-09-03T21:31:17Z",
  "published": "2026-09-03T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9736"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7284359"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QMX3-M648-HR74

Vulnerability from github – Published: 2022-06-23 00:00 – Updated: 2022-07-05 18:03

Summary

Log Injection in Apache Sling Commons Log and Apache Sling API

Details

Apache Sling Commons Log <= 5.4.0 and Apache Sling API <= 2.25.0 are vulnerable to log injection. The ability to forge logs may allow an attacker to cover tracks by injecting fake logs and potentially corrupt log files.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.sling:org.apache.sling.commons.log"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.sling:org.apache.sling.api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-32549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-117"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-23T17:48:50Z",
    "nvd_published_at": "2022-06-22T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Apache Sling Commons Log \u003c= 5.4.0 and Apache Sling API \u003c= 2.25.0 are vulnerable to log injection. The ability to forge logs may allow an attacker to cover tracks by injecting fake logs and potentially corrupt log files.",
  "id": "GHSA-qmx3-m648-hr74",
  "modified": "2022-07-05T18:03:15Z",
  "published": "2022-06-23T00:00:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32549"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/7z6h3806mwcov5kx6l96pq839sn0po1v"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Log Injection in Apache Sling Commons Log and Apache Sling API"
}

GHSA-QRH5-JG98-CR48

Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-11-05 20:45

Summary

Jenkins has a log message injection vulnerability

Details

In Jenkins 2.527 and earlier, LTS 2.516.2 and earlier, the log formatter that prepares log messages for console output (including jenkins.log and equivalent) does not restrict or transform the characters that can be inserted from user-specified content in log messages.

This allows attackers able to control log message contents to insert line break characters, followed by forged log messages that may mislead administrators reviewing log output.

Jenkins 2.528, LTS 2.516.3 adds an indicator at the beginning of a line that was inserted as part of log message content: [CR], [LF], or [CRLF] (representing the kind of line break), followed by > .

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.516.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.517"
            },
            {
              "fixed": "2.528"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-17T20:35:34Z",
    "nvd_published_at": "2025-09-17T14:15:41Z",
    "severity": "MODERATE"
  },
  "details": "In Jenkins 2.527 and earlier, LTS 2.516.2 and earlier, the log formatter that prepares log messages for console output (including `jenkins.log` and equivalent) does not restrict or transform the characters that can be inserted from user-specified content in log messages.\n\nThis allows attackers able to control log message contents to insert line break characters, followed by forged log messages that may mislead administrators reviewing log output.\n\nJenkins 2.528, LTS 2.516.3 adds an indicator at the beginning of a line that was inserted as part of log message content: `[CR]`, `[LF]`, or `[CRLF]` (representing the kind of line break), followed by `\u003e` .",
  "id": "GHSA-qrh5-jg98-cr48",
  "modified": "2025-11-05T20:45:10Z",
  "published": "2025-09-17T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59476"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/jenkins"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2025-09-17/#SECURITY-3424"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/09/17/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins has a log message injection vulnerability"
}

GHSA-QWVC-M955-QJ8V

Vulnerability from github – Published: 2026-03-26 00:30 – Updated: 2026-03-26 00:30

Details

IBM Maximo Application Suite - Monitor Component 9.1, 9.0, 8.11, and 8.10 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.

Severity

4.0 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-14684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T22:16:18Z",
    "severity": "MODERATE"
  },
  "details": "IBM Maximo Application Suite - Monitor Component 9.1, 9.0, 8.11, and 8.10 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.",
  "id": "GHSA-qwvc-m955-qj8v",
  "modified": "2026-03-26T00:30:55Z",
  "published": "2026-03-26T00:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14684"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7267481"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R8P9-94V3-7G9H

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30

Details

Triangle MicroWorks SCADA Data Gateway Event Log Improper Output Neutralization For Logs Arbitrary File Write Vulnerability. This vulnerability allows remote attackers to write arbitrary files on affected installations of Triangle MicroWorks SCADA Data Gateway. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.

The specific flaw exists within the handling of event logs. The issue results from improper sanitization of log output. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-20535.

Severity

4.4 (Medium)


                  
                    CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-39461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T03:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Triangle MicroWorks SCADA Data Gateway Event Log Improper Output Neutralization For Logs Arbitrary File Write Vulnerability. This vulnerability allows remote attackers to write arbitrary files on affected installations of Triangle MicroWorks SCADA Data Gateway. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.\n\nThe specific flaw exists within the handling of event logs. The issue results from improper sanitization of log output. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-20535.",
  "id": "GHSA-r8p9-94v3-7g9h",
  "modified": "2024-05-03T03:30:56Z",
  "published": "2024-05-03T03:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39461"
    },
    {
      "type": "WEB",
      "url": "https://www.trianglemicroworks.com/products/scada-data-gateway/what\u0027s-new"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-1029"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-5

Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Mitigation MIT-30

Implementation

Strategy: Output Encoding

Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

Mitigation MIT-20

Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CAPEC-268: Audit Log Manipulation

The attacker injects, manipulates, deletes, or forges malicious log entries into the log file, in an attempt to mislead an audit of the log file or cover tracks of an attack. Due to either insufficient access controls of the log files or the logging mechanism, the attacker is able to perform such actions.

CAPEC-81: Web Server Logs Tampering

Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.

CAPEC-93: Log Injection-Tampering-Forging

This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing them to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability.

← Back to the CWE list

CWE-117

Improper Output Neutralization for Logs

Impact

Patches

Workarounds

References

For more information

Root Cause

Impact

Proof of Concept

Body vector — reachable via stock coraza/v3/http + net/http

Header vector — reachable via non-net/http integrations only

Mitigation

Additional defensive measure

Affected versions

References

Mitigation MIT-5

Mitigation MIT-30

Mitigation MIT-20

CAPEC-268: Audit Log Manipulation

CAPEC-81: Web Server Logs Tampering

CAPEC-93: Log Injection-Tampering-Forging

Body vector — reachable via stock `coraza/v3/http` + `net/http`