Common Weakness Enumeration

CWE-93

Allowed

Improper Neutralization of CRLF Sequences ('CRLF Injection')

Abstraction: Base · Status: Draft

The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.

385 vulnerabilities reference this CWE, most recent first.

GHSA-875J-77W8-R9FV

Vulnerability from github – Published: 2025-05-26 12:30 – Updated: 2025-05-26 12:30
VLAI
Details

SQL injection vulnerability in AES Multimedia's Gestnet v1.07. This vulnerability allows an attacker to retrieve, create, update and delete databases via the ‘fk_remoto_central’ parameter on the ‘/webservices/articles.php’ endpoint.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-40671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-26T10:15:20Z",
    "severity": "CRITICAL"
  },
  "details": "SQL injection vulnerability in AES Multimedia\u0027s Gestnet v1.07. This vulnerability allows an attacker to retrieve, create, update and delete databases via the \u2018fk_remoto_central\u2019 parameter on the \u2018/webservices/articles.php\u2019 endpoint.",
  "id": "GHSA-875j-77w8-r9fv",
  "modified": "2025-05-26T12:30:30Z",
  "published": "2025-05-26T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40671"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/sql-injection-vulnerability-aes-multimedias-gestnet"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-89FF-5R66-WR8J

Vulnerability from github – Published: 2022-05-13 01:11 – Updated: 2022-05-13 01:11
VLAI
Details

An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \r\n (specifically in the path component of a URL that lacks a ? character) followed by an HTTP header or a Redis command. This is similar to the CVE-2019-9740 query string issue. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-9947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-23T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \\r\\n (specifically in the path component of a URL that lacks a ? character) followed by an HTTP header or a Redis command. This is similar to the CVE-2019-9740 query string issue. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.",
  "id": "GHSA-89ff-5r66-wr8j",
  "modified": "2022-05-13T01:11:47Z",
  "published": "2022-05-13T01:11:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9947"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4127-2"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4127-1"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190404-0004"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202003-26"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JXASHCDD4PQFKTMKQN4YOP5ZH366ABN4"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JMWSKTNOHSUOT3L25QFJAVCFYZX46FYK"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/08/msg00034.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/07/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/06/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/06/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/06/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://bugs.python.org/issue35906"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3725"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3520"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3335"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2030"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:1260"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00062.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00063.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00040.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/02/04/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8C48-Q9WJ-3W37

Vulnerability from github – Published: 2026-08-05 20:33 – Updated: 2026-08-05 20:33
VLAI
Summary
rclone: FTP Command Arguments Permit CRLF Injection When Custom Encoding Preserves Newlines
Details

1. Summary

A valid but nondefault FTP filename encoding can restore raw CR/LF immediately before an attacker-controlled path is interpolated into the line-oriented FTP control channel. The dependency does not reject CR or LF in command arguments, so a filename can inject an independent authenticated command. A real test server observed the injected DELE command.

The default FTP encoding and the configuration-wizard examples include Ctl and are not vulnerable to the demonstrated filename. A manual custom encoding that omits Ctl/CrLf is mandatory and is reflected as High attack complexity. The credible trust boundary is a lower-trust source namespace feeding a more-privileged FTP destination: if the attacker already has equivalent rights on that destination, the report establishes a bug but no privilege gain. Protocol framing must still be enforced at the command sink because a filename-compatibility encoder is not a safe substitute for command-argument validation.

2. Affected Assets & Attack Surface

  • Verified rclone revision: a0c09f1381ae93e2a9a33c529d170186c61ad058 (v1.74.0-240-ga0c09f138)
  • Current-master check: the relevant paths remained present at commit 961266888fe797390c535386f3b3aa46f4853602 on 2026-07-18
  • rclone FTP encoding: backend/ftp/ftp.go:232-248, 768-785
  • Encoder masks/conversion: lib/encoder/encoder.go:36-68, 121-152, 1144-1165
  • FTP command sinks: backend/ftp/ftp.go:1071-1173, 1309-1428
  • Dependency: github.com/jlaffaye/ftp@v0.2.1-0.20251026020404-6602e981a1bb
  • Dependency command formatting: ftp.go:604-610, with path-bearing callers at ftp.go:893-947, 1010-1026, and 1069-1080
  • Preconditions: an attacker can create a filename in a source namespace, the victim copies/syncs it to an FTP destination with greater authority, and that destination uses a manually configured encoding that leaves CR/LF raw
  • Platform note: Unix and some remote backends can supply newline-bearing names; a local Windows source cannot create the demonstrated filename

3. Technical Root Cause Analysis

Rclone represents control characters safely in its internal Standard encoding. Immediately before an FTP operation, FromStandardPath decodes that representation and applies the configured backend mask. If the mask omits Ctl/CrLf, raw newlines are restored. The dependency then formats the resulting argument onto a CRLF-delimited control stream through textproto.Conn.Cmd without validating it. Reversible filename representation is therefore being used as the only protection for a protocol-command boundary.

4. Proof-of-Concept & Evidence

The source filename was equivalent to:

victim\r\nDELE other-secret\r\nNOOP

With the default encoding, no raw newline reached the command. With the valid nondefault configuration encoding = Slash, FromStandardPath restored raw CRLF. During a real FTP path operation, the server parsed DELE other-secret as an independent authenticated command. This establishes injection, not merely unsafe serialization. The test did not establish confidentiality impact or operating-system command execution.

5. Impact Assessment

Injected commands run with the configured FTP account's permissions. Demonstrated direct impact is deletion of a different path, with corresponding integrity and availability loss inside that account. Other FTP filesystem commands may be reachable, but confidentiality and arbitrary operating-system command execution are not claimed. The privilege-boundary case requires the victim's FTP account to have more authority than the attacker has in the source namespace.

6. Remediation Guidance

  • Reject CR and LF in every FTP command argument at the lowest command-construction boundary.
  • Apply the check to paths, usernames, passwords, rename arguments, and all other formatted fields.
  • Return an error rather than silently normalizing an unsafe argument.
  • Keep the default encoder protection as defense in depth and reject an FTP encoding configuration that can restore CR/LF.
  • Add end-to-end tests for CR, LF, CRLF, and each path command.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.75.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-05T20:33:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## 1. Summary\n\nA valid but nondefault FTP filename encoding can restore raw CR/LF immediately before an attacker-controlled path is interpolated into the line-oriented FTP control channel. The dependency does not reject CR or LF in command arguments, so a filename can inject an independent authenticated command. A real test server observed the injected `DELE` command.\n\nThe default FTP encoding and the configuration-wizard examples include `Ctl` and are not vulnerable to the demonstrated filename. A manual custom encoding that omits `Ctl`/`CrLf` is mandatory and is reflected as High attack complexity. The credible trust boundary is a lower-trust source namespace feeding a more-privileged FTP destination: if the attacker already has equivalent rights on that destination, the report establishes a bug but no privilege gain. Protocol framing must still be enforced at the command sink because a filename-compatibility encoder is not a safe substitute for command-argument validation.\n\n## 2. Affected Assets \u0026 Attack Surface\n\n- Verified rclone revision: `a0c09f1381ae93e2a9a33c529d170186c61ad058` (`v1.74.0-240-ga0c09f138`)\n- Current-master check: the relevant paths remained present at commit `961266888fe797390c535386f3b3aa46f4853602` on 2026-07-18\n- rclone FTP encoding: `backend/ftp/ftp.go:232-248`, `768-785`\n- Encoder masks/conversion: `lib/encoder/encoder.go:36-68`, `121-152`, `1144-1165`\n- FTP command sinks: `backend/ftp/ftp.go:1071-1173`, `1309-1428`\n- Dependency: `github.com/jlaffaye/ftp@v0.2.1-0.20251026020404-6602e981a1bb`\n- Dependency command formatting: `ftp.go:604-610`, with path-bearing callers at `ftp.go:893-947`, `1010-1026`, and `1069-1080`\n- Preconditions: an attacker can create a filename in a source namespace, the victim copies/syncs it to an FTP destination with greater authority, and that destination uses a manually configured encoding that leaves CR/LF raw\n- Platform note: Unix and some remote backends can supply newline-bearing names; a local Windows source cannot create the demonstrated filename\n\n## 3. Technical Root Cause Analysis\n\nRclone represents control characters safely in its internal Standard encoding. Immediately before an FTP operation, `FromStandardPath` decodes that representation and applies the configured backend mask. If the mask omits `Ctl`/`CrLf`, raw newlines are restored. The dependency then formats the resulting argument onto a CRLF-delimited control stream through `textproto.Conn.Cmd` without validating it. Reversible filename representation is therefore being used as the only protection for a protocol-command boundary.\n\n## 4. Proof-of-Concept \u0026 Evidence\n\nThe source filename was equivalent to:\n\n```text\nvictim\\r\\nDELE other-secret\\r\\nNOOP\n```\n\nWith the default encoding, no raw newline reached the command. With the valid nondefault configuration `encoding = Slash`, `FromStandardPath` restored raw CRLF. During a real FTP path operation, the server parsed `DELE other-secret` as an independent authenticated command. This establishes injection, not merely unsafe serialization. The test did not establish confidentiality impact or operating-system command execution.\n\n## 5. Impact Assessment\n\nInjected commands run with the configured FTP account\u0027s permissions. Demonstrated direct impact is deletion of a different path, with corresponding integrity and availability loss inside that account. Other FTP filesystem commands may be reachable, but confidentiality and arbitrary operating-system command execution are not claimed. The privilege-boundary case requires the victim\u0027s FTP account to have more authority than the attacker has in the source namespace.\n\n## 6. Remediation Guidance\n\n- Reject CR and LF in every FTP command argument at the lowest command-construction boundary.\n- Apply the check to paths, usernames, passwords, rename arguments, and all other formatted fields.\n- Return an error rather than silently normalizing an unsafe argument.\n- Keep the default encoder protection as defense in depth and reject an FTP encoding configuration that can restore CR/LF.\n- Add end-to-end tests for CR, LF, CRLF, and each path command.",
  "id": "GHSA-8c48-q9wj-3w37",
  "modified": "2026-08-05T20:33:57Z",
  "published": "2026-08-05T20:33:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-8c48-q9wj-3w37"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/1df2b70753286c1dfe8366078cbedfdf7f96472c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: FTP Command Arguments Permit CRLF Injection When Custom Encoding Preserves Newlines"
}

GHSA-8CGQ-6MH2-7J6V

Vulnerability from github – Published: 2025-03-04 15:27 – Updated: 2025-11-04 16:55
VLAI
Summary
Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection
Details

Summary

Rack::Sendfile can be exploited by crafting input that includes newline characters to manipulate log entries.

Details

The Rack::Sendfile middleware logs unsanitized header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection.

Impact

This vulnerability can distort log files, obscure attack traces, and complicate security auditing.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Sendfile.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1"
            },
            {
              "fixed": "3.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27111"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-04T15:27:06Z",
    "nvd_published_at": "2025-03-04T16:15:40Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`Rack::Sendfile` can be exploited by crafting input that includes newline characters to manipulate log entries.\n\n## Details\n\nThe `Rack::Sendfile` middleware logs unsanitized header values from the `X-Sendfile-Type` header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection.\n\n## Impact\n\nThis vulnerability can distort log files, obscure attack traces, and complicate security auditing.\n\n## Mitigation\n\n- Update to the latest version of Rack, or\n- Remove usage of `Rack::Sendfile`.",
  "id": "GHSA-8cgq-6mh2-7j6v",
  "modified": "2025-11-04T16:55:18Z",
  "published": "2025-03-04T15:27:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-8cgq-6mh2-7j6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27111"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/803aa221e8302719715e224f4476e438f2531a53"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/aeac570bb8080ca7b53b7f2e2f67498be7ebd30b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/b13bc6bfc7506aca3478dc5ac1c2ec6fc53f82a3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-27111.yml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00016.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection"
}

GHSA-8H6H-X5PQ-56FQ

Vulnerability from github – Published: 2026-08-26 14:28 – Updated: 2026-08-26 14:28
VLAI
Summary
@logtape/syslog: syslog log injection via unescaped control characters and unvalidated SD-NAME keys
Details

@logtape/syslog contains two related output-encoding bugs in the structured data formatting code. Both only affect deployments with includeStructuredData: true, which is non-default.

1. Unescaped C0 control characters in structured data values

escapeStructuredDataValue() in packages/syslog/src/syslog.ts escapes \, ", and ] per RFC 5424 but does not escape newline (\n), carriage return (\r), or any other C0 control characters (U+0000–U+001F):

function escapeStructuredDataValue(value: string): string {
  return value
    .replace(/\\/g, "\\\\")
    .replace(/"/g, '\\"')
    .replace(/]/g, "\\]");
  // \n, \r, and other C0 control characters are not escaped
}

TCP syslog commonly uses \n as a frame delimiter (RFC 6587, non-transparent framing). If an attacker-controlled value contains a literal newline, that newline terminates the current syslog frame. Bytes following the newline begin a new frame, and if they form a valid RFC 5424 header (<PRI>1 …), a downstream collector will accept them as a separate, authentic-looking syslog record.

2. Unvalidated SD-NAME keys

Structured data parameter keys are inserted into the message without validation or escaping:

elements.push(`${key}="${escapedValue}"`);

RFC 5424 defines SD-NAME as printable US-ASCII characters excluding =, ], ", and space, with a maximum length of 32. A key containing any of those characters, control characters, or exceeding the length limit will produce malformed structured data. If the key itself contains an embedded ], it can prematurely close the structured-data element.

In typical usage, property keys are developer-defined string literals and therefore safe. However, if an application forwards attacker-controlled keys as log properties—for example by spreading request headers or arbitrary metadata into a log record—this becomes a second injection path.

Proof of concept

The following Node.js snippet (no dependencies, no network required) demonstrates that the escaped value still contains a literal newline:

function escapeStructuredDataValue(value) {
  return value
    .replace(/\\/g, "\\\\")
    .replace(/"/g, '\\"')
    .replace(/]/g, "\\]");
}

const payload =
  'normal\n<134>1 2026-01-01T00:00:00Z forged evil - - - INJECTED';

const result = escapeStructuredDataValue(payload);
console.log("Newline present after escape:", result.includes("\n")); // true

Tested with Node.js 22.17.1.

Impact

An attacker who controls log property values can:

  • forge syslog records attributed to arbitrary hosts, applications, or process IDs;
  • insert records with arbitrary severity or facility levels;
  • obscure malicious activity by injecting misleading entries around legitimate ones;
  • break downstream log parsers or SIEM correlation rules that rely on log integrity.

Affected downstream collectors include rsyslog, syslog-ng, Splunk, Elastic Stack, and any other system using RFC 6587 non-transparent framing.

Suggested fix

Structured data values

Escape all C0 control characters (U+0000–U+001F) in addition to \, ", and ]. RFC 5424 does not define an escape sequence for control characters in PARAM-VALUE; the most interoperable approach is to strip or replace them:

function escapeStructuredDataValue(value: string): string {
  return value
    .replace(/\\/g, "\\\\")
    .replace(/"/g, '\\"')
    .replace(/]/g, "\\]")
    .replace(/[\x00-\x1f]/g, (c) =>
      `\\x${c.charCodeAt(0).toString(16).padStart(2, "0")}`
    );
}

Alternatively, strip them entirely: .replace(/[\x00-\x1f]/g, ""). The right choice depends on whether downstream consumers need some representation of the original value.

SD-NAME keys

Validate each key against the RFC 5424 SD-NAME grammar before including it. Keys that fail validation should be skipped or sanitized:

// SD-NAME: printable US-ASCII, excluding '=', ']', '"', SP; max 32 chars
const SD_NAME_RE = /^[!-<>-Z\\^-z|~]{1,32}$/;

for (const [key, value] of Object.entries(record.properties)) {
  if (!SD_NAME_RE.test(key)) continue;
  const escapedValue = escapeStructuredDataValue(String(value));
  elements.push(`${key}="${escapedValue}"`);
}
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@logtape/syslog"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@logtape/syslog"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@logtape/syslog"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-26T14:28:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`@logtape/syslog` contains two related output-encoding bugs in the structured data formatting code. Both only affect deployments with `includeStructuredData: true`, which is non-default.\n\n## 1. Unescaped C0 control characters in structured data values\n\n`escapeStructuredDataValue()` in `packages/syslog/src/syslog.ts` escapes `\\`, `\"`, and `]` per RFC 5424 but does not escape newline (`\\n`), carriage return (`\\r`), or any other C0 control characters (U+0000\u2013U+001F):\n\n```typescript\nfunction escapeStructuredDataValue(value: string): string {\n  return value\n    .replace(/\\\\/g, \"\\\\\\\\\")\n    .replace(/\"/g, \u0027\\\\\"\u0027)\n    .replace(/]/g, \"\\\\]\");\n  // \\n, \\r, and other C0 control characters are not escaped\n}\n```\n\nTCP syslog commonly uses `\\n` as a frame delimiter (RFC 6587, non-transparent framing). If an attacker-controlled value contains a literal newline, that newline terminates the current syslog frame. Bytes following the newline begin a new frame, and if they form a valid RFC 5424 header (`\u003cPRI\u003e1 \u2026`), a downstream collector will accept them as a separate, authentic-looking syslog record.\n\n## 2. Unvalidated SD-NAME keys\n\nStructured data parameter keys are inserted into the message without validation or escaping:\n\n```typescript\nelements.push(`${key}=\"${escapedValue}\"`);\n```\n\nRFC 5424 defines SD-NAME as printable US-ASCII characters excluding `=`, `]`, `\"`, and space, with a maximum length of 32. A key containing any of those characters, control characters, or exceeding the length limit will produce malformed structured data. If the key itself contains an embedded `]`, it can prematurely close the structured-data element.\n\nIn typical usage, property keys are developer-defined string literals and therefore safe. However, if an application forwards attacker-controlled keys as log properties\u2014for example by spreading request headers or arbitrary metadata into a log record\u2014this becomes a second injection path.\n\n## Proof of concept\n\nThe following Node.js snippet (no dependencies, no network required) demonstrates that the escaped value still contains a literal newline:\n\n```javascript\nfunction escapeStructuredDataValue(value) {\n  return value\n    .replace(/\\\\/g, \"\\\\\\\\\")\n    .replace(/\"/g, \u0027\\\\\"\u0027)\n    .replace(/]/g, \"\\\\]\");\n}\n\nconst payload =\n  \u0027normal\\n\u003c134\u003e1 2026-01-01T00:00:00Z forged evil - - - INJECTED\u0027;\n\nconst result = escapeStructuredDataValue(payload);\nconsole.log(\"Newline present after escape:\", result.includes(\"\\n\")); // true\n```\n\nTested with Node.js 22.17.1.\n\n## Impact\n\nAn attacker who controls log property values can:\n\n- forge syslog records attributed to arbitrary hosts, applications, or process IDs;\n- insert records with arbitrary severity or facility levels;\n- obscure malicious activity by injecting misleading entries around legitimate ones;\n- break downstream log parsers or SIEM correlation rules that rely on log integrity.\n\nAffected downstream collectors include rsyslog, syslog-ng, Splunk, Elastic Stack, and any other system using RFC 6587 non-transparent framing.\n\n## Suggested fix\n\n### Structured data values\n\nEscape all C0 control characters (U+0000\u2013U+001F) in addition to `\\`, `\"`, and `]`. RFC 5424 does not define an escape sequence for control characters in PARAM-VALUE; the most interoperable approach is to strip or replace them:\n\n```typescript\nfunction escapeStructuredDataValue(value: string): string {\n  return value\n    .replace(/\\\\/g, \"\\\\\\\\\")\n    .replace(/\"/g, \u0027\\\\\"\u0027)\n    .replace(/]/g, \"\\\\]\")\n    .replace(/[\\x00-\\x1f]/g, (c) =\u003e\n      `\\\\x${c.charCodeAt(0).toString(16).padStart(2, \"0\")}`\n    );\n}\n```\n\nAlternatively, strip them entirely: `.replace(/[\\x00-\\x1f]/g, \"\")`. The right choice depends on whether downstream consumers need some representation of the original value.\n\n### SD-NAME keys\n\nValidate each key against the RFC 5424 SD-NAME grammar before including it. Keys that fail validation should be skipped or sanitized:\n\n```typescript\n// SD-NAME: printable US-ASCII, excluding \u0027=\u0027, \u0027]\u0027, \u0027\"\u0027, SP; max 32 chars\nconst SD_NAME_RE = /^[!-\u003c\u003e-Z\\\\^-z|~]{1,32}$/;\n\nfor (const [key, value] of Object.entries(record.properties)) {\n  if (!SD_NAME_RE.test(key)) continue;\n  const escapedValue = escapeStructuredDataValue(String(value));\n  elements.push(`${key}=\"${escapedValue}\"`);\n}\n```",
  "id": "GHSA-8h6h-x5pq-56fq",
  "modified": "2026-08-26T14:28:04Z",
  "published": "2026-08-26T14:28:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/logtape/security/advisories/GHSA-8h6h-x5pq-56fq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/logtape/commit/7a6e5b9ddf7915edfff78fa129bc17c979b2a623"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dahlia/logtape"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/logtape/releases/tag/1.3.11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/logtape/releases/tag/2.0.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/logtape/releases/tag/2.1.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@logtape/syslog: syslog log injection via unescaped control characters and unvalidated SD-NAME keys"
}

GHSA-8P34-64R3-MWG8

Vulnerability from github – Published: 2026-06-09 18:36 – Updated: 2026-07-06 22:53
VLAI
Summary
Net::IMAP: Command Injection via non-synchronizing literal in "raw" argument
Details

Several Net::IMAP commands accept a "raw data" argument that is sent verbatim after validation to prevent command injection. However, if a server does not support non-synchronizing literals, it may still be possible to inject arbitrary IMAP commands inside non-synchronizing literals.

Details

Raw data arguments support embedded literal values, both synchronizing and non-synchronizing. Non-synchronizing literals can only be safely sent when the server advertises any of the LITERAL+, LITERAL-, or IMAP4rev2 capabilities. But raw data arguments do not verify server support for non-synchronizing literals prior to sending.

Servers without support for non-synchronizing literals could handle them in several different ways: If a server sees a "}\r\n" byte sequence but can't parse the literal bytesize, it may cautiously decide to close the connection, blocking any command injection attacks. However, a server without support for non-synchronizing literals may instead interpret the "+}\r\n" as the end of a malformed command line and respond with a tagged BAD. In that case, the contents of the literal will be interpreted as one or more new pipelined commands, allowing a CRLF command injection attack to succeed.

This affects the following commands' string arguments: * criteria for #search and #uid_search * search_keys for #sort, #thread, #uid_sort, and #uid_thread * attr for #fetch and #uid_fetch

Prior to net-imap v0.6.4, v0.5.14, and v0.4.24, raw data arguments were not validated in any way, so they were also vulnerable to this attack. See CVE-2026-42257 (GHSA-hm49-wcqc-g2xg).

Impact

Fortunately, LITERAL- is supported by most modern IMAP servers. Even without support for non-synchronizing literals, cautious servers may handle invalid literal bytesize by closing the connection . However, servers which handle a non-synchronizing literal just like any other malformed command will enable this vulnerability.

If a developer passes an unvalidated user-controlled input for one of these method arguments, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.

Mitigation

Update to a version of net-imap which validates server support for non-synchronizing literals before sending them.

If upgrading net-imap is not possible: * Explicitly validate user-controlled inputs to prevent embedded non-synchronizing literals unless the server supports them. * For a simpler, more cautious approach: all embedded literals can be unconditionally prohibited, by checking that string inputs do not contain any CR or LF bytes. * Verify that the server advertises any of the LITERAL+, LITERAL-, or IMAP4rev2 capabilities before using untrusted string inputs for the affected "raw data" arguments.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.14"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47240"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-77",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-09T18:36:04Z",
    "nvd_published_at": "2026-06-22T21:16:24Z",
    "severity": "MODERATE"
  },
  "details": "Several Net::IMAP commands accept a \"raw data\" argument that is sent verbatim after validation to prevent command injection.  However, if a server does not support non-synchronizing literals, it may still be possible to inject arbitrary IMAP commands inside non-synchronizing literals.\n\n### Details\n\nRaw data arguments support embedded literal values, both synchronizing and non-synchronizing.  Non-synchronizing literals can only be safely sent when the server advertises any of the `LITERAL+`, `LITERAL-`, or `IMAP4rev2` capabilities.  But raw data arguments do not verify server support for non-synchronizing literals prior to sending.\n\nServers without support for non-synchronizing literals could handle them in several different ways:  If a server sees a `\"}\\r\\n\"` byte sequence but can\u0027t parse the literal bytesize, it _may_ cautiously decide to close the connection, blocking any command injection attacks.  However, a server without support for non-synchronizing literals may instead interpret the `\"+}\\r\\n\"` as the end of a malformed command line and respond with a tagged `BAD`.  In that case, the contents of the literal will be interpreted as one or more new pipelined commands, allowing a CRLF command injection attack to succeed.\n\nThis affects the following commands\u0027 string arguments:\n* `criteria` for `#search` and `#uid_search`\n* `search_keys` for `#sort`, `#thread`, `#uid_sort`, and `#uid_thread`\n* `attr` for `#fetch` and `#uid_fetch`\n\nPrior to `net-imap` v0.6.4, v0.5.14, and v0.4.24, raw data arguments were not validated in _any_ way, so they were also vulnerable to this attack.  See CVE-2026-42257 (GHSA-hm49-wcqc-g2xg).\n\n### Impact\n\nFortunately, `LITERAL-` is supported by most modern IMAP servers.  Even without support for non-synchronizing literals, cautious servers may handle invalid literal bytesize by closing the connection .  However, servers which handle a non-synchronizing literal just like any other malformed command will enable this vulnerability.\n\nIf a developer passes an unvalidated user-controlled input for one of these method arguments, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system\u0027s attributes, e.g.: shared mail folders or the application\u0027s installed response handlers.\n\n### Mitigation\n\nUpdate to a version of `net-imap` which validates server support for non-synchronizing literals before sending them.\n\nIf upgrading `net-imap` is not possible:\n* Explicitly validate user-controlled inputs to prevent embedded non-synchronizing literals unless the server supports them.\n* For a simpler, more cautious approach: all embedded literals can be unconditionally prohibited, by checking that string inputs do not contain any CR or LF bytes.\n* Verify that the server advertises any of the `LITERAL+`, `LITERAL-`, or `IMAP4rev2` capabilities before using untrusted string inputs for the affected \"raw data\" arguments.",
  "id": "GHSA-8p34-64r3-mwg8",
  "modified": "2026-07-06T22:53:42Z",
  "published": "2026-06-09T18:36:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-8p34-64r3-mwg8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47240"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-47240.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47240"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Net::IMAP: Command Injection via non-synchronizing literal in \"raw\" argument"
}

GHSA-8PM5-XR39-VFV3

Vulnerability from github – Published: 2026-01-27 12:31 – Updated: 2026-03-19 15:31
VLAI
Details

A flaw was found in libsoup, an HTTP client library. This vulnerability, known as CRLF (Carriage Return Line Feed) Injection, occurs when an HTTP proxy is configured and the library improperly handles URL-decoded input used to create the Host header. A remote attacker can exploit this by providing a specially crafted URL containing CRLF sequences, allowing them to inject additional HTTP headers or complete HTTP request bodies. This can lead to unintended or unauthorized HTTP requests being forwarded by the proxy, potentially impacting downstream services.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-1467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-27T10:15:48Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in libsoup, an HTTP client library. This vulnerability, known as CRLF (Carriage Return Line Feed) Injection, occurs when an HTTP proxy is configured and the library improperly handles URL-decoded input used to create the Host header. A remote attacker can exploit this by providing a specially crafted URL containing CRLF sequences, allowing them to inject additional HTTP headers or complete HTTP request bodies. This can lead to unintended or unauthorized HTTP requests being forwarded by the proxy, potentially impacting downstream services.",
  "id": "GHSA-8pm5-xr39-vfv3",
  "modified": "2026-03-19T15:31:09Z",
  "published": "2026-01-27T12:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1467"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-1467"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2433174"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/488"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QV8-FQ5W-P966

Vulnerability from github – Published: 2021-12-16 14:26 – Updated: 2021-12-16 14:09
VLAI
Summary
phpservermon is vulnerable to CRLF Injection
Details

phpservermon is vulnerable to Improper Neutralization of CRLF Sequences.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpservermon/phpservermon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-4097"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-12-14T15:10:46Z",
    "nvd_published_at": "2021-12-12T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "phpservermon is vulnerable to Improper Neutralization of CRLF Sequences.",
  "id": "GHSA-8qv8-fq5w-p966",
  "modified": "2021-12-16T14:09:58Z",
  "published": "2021-12-16T14:26:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4097"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phpservermon/phpservermon/commit/162bba0046fcda1580f4fbc7b9ababe3c7c13ce4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/phpservermon/phpservermon"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/d617ced7-be06-4e34-9db0-63d45c003a43"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpservermon is vulnerable to CRLF Injection"
}

GHSA-9324-JV53-9CC8

Vulnerability from github – Published: 2023-03-21 22:41 – Updated: 2023-03-21 22:41
VLAI
Summary
dio vulnerable to CRLF injection with HTTP method string
Details

Impact

The dio package 4.0.0 for Dart allows CRLF injection if the attacker controls the HTTP method string, a different vulnerability than CVE-2020-35669.

Patches

The vulnerability has been resolved by https://github.com/cfug/dio/commit/927f79e93ba39f3c3a12c190624a55653d577984, and included since v5.0.0.

Workarounds

Cherry-pick the commit to your own fork can resolves the vulberability too.

References

  • https://nvd.nist.gov/vuln/detail/CVE-2021-31402
  • https://osv.dev/GHSA-jwpw-q68h-r678
  • https://github.com/cfug/dio/issues/1130
  • https://github.com/cfug/dio/issues/1752
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Pub",
        "name": "dio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-31402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-21T22:41:11Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThe dio package 4.0.0 for Dart allows CRLF injection if the attacker controls the HTTP method string, a different vulnerability than CVE-2020-35669.\n\n### Patches\nThe vulnerability has been resolved by https://github.com/cfug/dio/commit/927f79e93ba39f3c3a12c190624a55653d577984, and included since v5.0.0.\n\n### Workarounds\nCherry-pick the commit to your own fork can resolves the vulberability too.\n\n### References\n- https://nvd.nist.gov/vuln/detail/CVE-2021-31402\n- https://osv.dev/GHSA-jwpw-q68h-r678\n- https://github.com/cfug/dio/issues/1130\n- https://github.com/cfug/dio/issues/1752\n",
  "id": "GHSA-9324-jv53-9cc8",
  "modified": "2023-03-21T22:41:11Z",
  "published": "2023-03-21T22:41:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cfug/dio/security/advisories/GHSA-9324-jv53-9cc8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31402"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cfug/dio/issues/1752"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flutterchina/dio/issues/1130"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cfug/dio/commit/927f79e93ba39f3c3a12c190624a55653d577984"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cfug/dio"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/GHSA-jwpw-q68h-r678"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-PUB-DIO-5891148"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "dio vulnerable to CRLF injection with HTTP method string"
}

GHSA-95C2-PG6V-7HQP

Vulnerability from github – Published: 2026-07-01 06:31 – Updated: 2026-07-01 06:31
VLAI
Details

The WPForms – Easy Form Builder for WordPress – Contact Forms, Payment Forms, Surveys, & More plugin for WordPress is vulnerable to Improper Neutralization of CRLF Sequences ('CRLF Injection') in all versions up to, and including, 1.10.2 This is due to get_reply_to_address() processing the Reply-To display name through smart-tag expansion with context 'notification' instead of 'notification-reply-to', which bypasses email-address validation while wpforms_sanitize_textarea_field() intentionally preserves CR/LF characters that are never stripped before the display name is concatenated into the raw Reply-To: mail header string. This makes it possible for unauthenticated attackers to inject arbitrary additional email headers — such as Bcc: — into outgoing notification emails, silently blind-copying all notification email copies to an attacker-controlled address. Exploitation requires that a form notification is configured to use a Paragraph Text (textarea) field as the Reply-To display name via a Smart Tag.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-12127"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T05:16:17Z",
    "severity": "MODERATE"
  },
  "details": "The WPForms \u2013 Easy Form Builder for WordPress \u2013 Contact Forms, Payment Forms, Surveys, \u0026 More plugin for WordPress is vulnerable to Improper Neutralization of CRLF Sequences (\u0027CRLF Injection\u0027) in all versions up to, and including, 1.10.2 This is due to `get_reply_to_address()` processing the Reply-To display name through smart-tag expansion with context `\u0027notification\u0027` instead of `\u0027notification-reply-to\u0027`, which bypasses email-address validation while `wpforms_sanitize_textarea_field()` intentionally preserves CR/LF characters that are never stripped before the display name is concatenated into the raw `Reply-To:` mail header string. This makes it possible for unauthenticated attackers to inject arbitrary additional email headers \u2014 such as `Bcc:` \u2014 into outgoing notification emails, silently blind-copying all notification email copies to an attacker-controlled address. Exploitation requires that a form notification is configured to use a Paragraph Text (textarea) field as the Reply-To display name via a Smart Tag.",
  "id": "GHSA-95c2-pg6v-7hqp",
  "modified": "2026-07-01T06:31:33Z",
  "published": "2026-07-01T06:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12127"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.0.2/includes/fields/class-textarea.php#L326"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.0.2/src/Emails/Mailer.php#L368"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.0.2/src/Emails/Notifications.php#L1098"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.0.2/src/Emails/Notifications.php#L1138"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.1.1/includes/fields/class-textarea.php#L326"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.1.1/src/Emails/Mailer.php#L368"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.1.1/src/Emails/Notifications.php#L1098"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpforms-lite/tags/1.10.1.1/src/Emails/Notifications.php#L1138"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3586095/wpforms-lite/trunk/src/Emails/Mailer.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?old_path=%2Fwpforms-lite/tags/1.10.2\u0026new_path=%2Fwpforms-lite/tags/1.10.2.1"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d5a51c22-c4ca-4897-ad7e-c5df00b07fe0?source=cve"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Implementation

Avoid using CRLF as a special sequence.

Mitigation
Implementation

Appropriately filter or quote CRLF sequences in user-controlled input.

CAPEC-15: Command Delimiters

An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.

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.