Common Weakness Enumeration

CWE-93

Allowed

Improper Neutralization of CRLF Sequences ('CRLF Injection')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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.

323 vulnerabilities reference this CWE, most recent first.

GHSA-74P7-6H78-GW8P

Vulnerability from github – Published: 2026-06-22 22:45 – Updated: 2026-06-22 22:45
VLAI
Summary
skillctl: argument injection, path traversal in --dest, FIFO/device DoS, hardlink exfiltration, and commit-trailer forgery
Details

Impact

Following the path-safety patches in GHSA-wx3m-whqv-xv47 (v0.1.2), a comprehensive multi-angle audit surfaced five further vulnerabilities, now patched in v0.1.3:

  1. source_sha argument injection in git ls-tree (CRITICAL). InstalledSkill.source_sha deserialized from .skills.toml (committed, PR-mergeable) flowed unvalidated into git ls-tree -r -z <refspec> -- <path>. Because the refspec sits before --, an attacker who slipped a malicious .skills.toml into a PR could set source_sha = "--name-only" / --abbrev=0 / --output=… and corrupt the diff classifier (which drives pull / push destructive decisions), or forge a divergence state to trick push --on-divergence overwrite into clobbering the wrong content.
  2. FIFO / device / socket denial-of-service in copy_dir_all (CRITICAL). The file-type branch only checked is_dir() / is_symlink(); a FIFO inside a skill folder fell through to fs::copy, which blocks indefinitely waiting for a writer. A character device like /dev/zero would read until OOM. Reachable on skillctl add against any adversarial library.
  3. add --dest arbitrary-directory wipe in agent mode (HIGH). --dest accepted absolute paths and .. traversal without validation, so a single invocation skillctl add --dest /Users/victim/.ssh --on-conflict overwrite --skill <maliciously-named> would remove_dir_all arbitrary directories — no .skills.toml round-trip required. Reachable in any non-interactive / agent-driven workflow where flag values may be attacker-supplied.
  4. Commit-message trailer forgery via skill names (HIGH). Skill names were spliced verbatim into git commit -m "update skill: <name>" and into the commit.message field of --json output. A skill named foo\nCo-Authored-By: evil@x produced a forged commit trailer that downstream tooling (Linear, GitHub commit-bot, release-notes scrapers) treats as real authorship metadata.
  5. Hardlink exfiltration via the round-trip (HIGH). fs::symlink_metadata reports a regular file for hardlinks (shared inode), and fs::copy reads the target content. An untrusted agent writing <project>/my-skill/data as a hardlink to ~/.ssh/id_rsa would have shipped the SSH key content to the (possibly public) library on the next skillctl push or detect.

Patches

Fixed in v0.1.3:

  • InstalledSkill::validate rejects any source_sha that isn't 40–64 hex characters.
  • fs_util::copy_dir_all only allows regular files and directories; FIFO / socket / device / other special files are rejected with AppError::Config.
  • commands::add::resolve_destination rejects .. unconditionally and rejects absolute paths in non-interactive / --json mode.
  • New src/sanitize.rs module: validate_identifier (strict, no control bytes / newlines / ESC, used for skill name + individual tags) and validate_message_safe (lenient, allows \n + \t, rejects \r + DEL + C0/C1 controls, used for description and --message). Wired at the skill::discover and read_tags boundaries so poisoned skills are dropped silently and poisoned descriptions/tags are stripped from otherwise-valid skills.
  • fs_util::copy_dir_all checks metadata.nlink() > 1 on regular files (Unix) and refuses hardlinked content.

All checks are lexical or single-syscall (symlink_metadata, metadata). No canonicalize, no TOCTOU windows. 23 new unit + integration tests cover each rejection class; cargo test: 95 pass; clippy clean; cargo audit clean.

Workarounds

Upgrade to v0.1.3. Pre-patch mitigations are awkward but possible: - Audit every .skills.toml source_sha field before running skillctl pull / push / detect. - Audit library content for FIFO / device files and hardlinks before running skillctl add. - Never invoke skillctl add with attacker-controllable --dest values in agent / CI contexts. - Never use --message with attacker-controlled content.

Credit

The findings were surfaced by a maintainer-led multi-angle audit (6 parallel sub-agents, one per threat-model dimension) following the firebaguette audit that motivated v0.1.2. The methodology (cross-agent convergence to identify the most exploitable items) is documented in the project's internal decisions log; the strongest signal was the four-of-six independent convergence on the source_sha vector.

Resources

  • Fix commit: 28dfce3
  • Release: https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3
  • Prior advisory (path-safety + symlinks): GHSA-wx3m-whqv-xv47
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "skillctl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-400",
      "CWE-59",
      "CWE-88",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T22:45:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nFollowing the path-safety patches in [GHSA-wx3m-whqv-xv47](https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47) (v0.1.2), a comprehensive multi-angle audit surfaced five further vulnerabilities, now patched in v0.1.3:\n\n1. **`source_sha` argument injection in `git ls-tree` (CRITICAL).** `InstalledSkill.source_sha` deserialized from `.skills.toml` (committed, PR-mergeable) flowed unvalidated into `git ls-tree -r -z \u003crefspec\u003e -- \u003cpath\u003e`. Because the refspec sits before `--`, an attacker who slipped a malicious `.skills.toml` into a PR could set `source_sha = \"--name-only\"` / `--abbrev=0` / `--output=\u2026` and corrupt the diff classifier (which drives `pull` / `push` destructive decisions), or forge a divergence state to trick `push --on-divergence overwrite` into clobbering the wrong content.\n2. **FIFO / device / socket denial-of-service in `copy_dir_all` (CRITICAL).** The file-type branch only checked `is_dir()` / `is_symlink()`; a FIFO inside a skill folder fell through to `fs::copy`, which blocks indefinitely waiting for a writer. A character device like `/dev/zero` would read until OOM. Reachable on `skillctl add` against any adversarial library.\n3. **`add --dest` arbitrary-directory wipe in agent mode (HIGH).** `--dest` accepted absolute paths and `..` traversal without validation, so a single invocation `skillctl add --dest /Users/victim/.ssh --on-conflict overwrite --skill \u003cmaliciously-named\u003e` would `remove_dir_all` arbitrary directories \u2014 no `.skills.toml` round-trip required. Reachable in any non-interactive / agent-driven workflow where flag values may be attacker-supplied.\n4. **Commit-message trailer forgery via skill names (HIGH).** Skill names were spliced verbatim into `git commit -m \"update skill: \u003cname\u003e\"` and into the `commit.message` field of `--json` output. A skill named `foo\\nCo-Authored-By: evil@x` produced a forged commit trailer that downstream tooling (Linear, GitHub commit-bot, release-notes scrapers) treats as real authorship metadata.\n5. **Hardlink exfiltration via the round-trip (HIGH).** `fs::symlink_metadata` reports a regular file for hardlinks (shared inode), and `fs::copy` reads the target content. An untrusted agent writing `\u003cproject\u003e/my-skill/data` as a hardlink to `~/.ssh/id_rsa` would have shipped the SSH key content to the (possibly public) library on the next `skillctl push` or `detect`.\n\n## Patches\n\nFixed in [v0.1.3](https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3):\n\n- `InstalledSkill::validate` rejects any `source_sha` that isn\u0027t 40\u201364 hex characters.\n- `fs_util::copy_dir_all` only allows regular files and directories; FIFO / socket / device / other special files are rejected with `AppError::Config`.\n- `commands::add::resolve_destination` rejects `..` unconditionally and rejects absolute paths in non-interactive / `--json` mode.\n- New `src/sanitize.rs` module: `validate_identifier` (strict, no control bytes / newlines / ESC, used for skill `name` + individual `tags`) and `validate_message_safe` (lenient, allows `\\n` + `\\t`, rejects `\\r` + DEL + C0/C1 controls, used for `description` and `--message`). Wired at the `skill::discover` and `read_tags` boundaries so poisoned skills are dropped silently and poisoned descriptions/tags are stripped from otherwise-valid skills.\n- `fs_util::copy_dir_all` checks `metadata.nlink() \u003e 1` on regular files (Unix) and refuses hardlinked content.\n\nAll checks are lexical or single-syscall (`symlink_metadata`, `metadata`). No `canonicalize`, no TOCTOU windows. 23 new unit + integration tests cover each rejection class; `cargo test`: 95 pass; clippy clean; `cargo audit` clean.\n\n## Workarounds\n\nUpgrade to v0.1.3. Pre-patch mitigations are awkward but possible:\n- Audit every `.skills.toml` `source_sha` field before running `skillctl pull` / `push` / `detect`.\n- Audit library content for FIFO / device files and hardlinks before running `skillctl add`.\n- Never invoke `skillctl add` with attacker-controllable `--dest` values in agent / CI contexts.\n- Never use `--message` with attacker-controlled content.\n\n## Credit\n\nThe findings were surfaced by a maintainer-led multi-angle audit (6 parallel sub-agents, one per threat-model dimension) following the firebaguette audit that motivated v0.1.2. The methodology (cross-agent convergence to identify the most exploitable items) is documented in the project\u0027s internal decisions log; the strongest signal was the four-of-six independent convergence on the `source_sha` vector.\n\n## Resources\n\n- Fix commit: [28dfce3](https://github.com/umanio-agency/skillctl/commit/28dfce3)\n- Release: https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3\n- Prior advisory (path-safety + symlinks): [GHSA-wx3m-whqv-xv47](https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47)",
  "id": "GHSA-74p7-6h78-gw8p",
  "modified": "2026-06-22T22:45:16Z",
  "published": "2026-06-22T22:45:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/security/advisories/GHSA-74p7-6h78-gw8p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/commit/28dfce3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umanio-agency/skillctl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "skillctl: argument injection, path traversal in --dest, FIFO/device DoS, hardlink exfiltration, and commit-trailer forgery"
}

GHSA-75XQ-5H9V-W6PX

Vulnerability from github – Published: 2026-05-04 22:04 – Updated: 2026-05-14 20:49
VLAI
Summary
net-imap vulnerable to command Injection via unvalidated Symbol inputs
Details

Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.

Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a "\" prefix. Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid flag characters, including SP and CRLF, which could be used to finish the current command and inject new commands.

Although IMAP flag arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (flag) inputs.

Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics. Any user-provided values outside of that list of standard "system flags" needs to use the IMAP keyword syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should #to_sym ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that user_input_atom is as \user_input_atom.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list. That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox).

Mitigation

  • Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP flag.
  • User-provided input should never be able to control calling #to_sym on string arguments.

For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments. * For the few IMAP commands which do allow flag arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.

Severity
5.8 (Medium)
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.23"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-77",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:04:08Z",
    "nvd_published_at": "2026-05-09T20:16:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nSymbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.\n\n### Details\n\nSymbol arguments represent IMAP \"system flags\", which are formatted as \"atoms\" (with no quoting) with a `\"\\\"` prefix.  Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.\n\nBecause the Symbol input is unvalidated, it could contain invalid `flag` characters, including `SP` and `CRLF`, which could be used to finish the current command and inject new commands.\n\nAlthough IMAP `flag` arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (`flag`) inputs.\n\nNote also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics.  Any user-provided values outside of that list of standard \"system flags\" needs to use the IMAP `keyword` syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should `#to_sym` ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that `user_input_atom` is  as `\\user_input_atom`.\n\nFor forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list.  That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.\n\n### Impact\n\nIf a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like `DELETE mailbox`).\n\n### Mitigation\n* Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP `flag`.\n* User-provided input should never be able to control calling `#to_sym` on string arguments.\n\n  For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments.\n* For the few IMAP commands which do allow `flag` arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.",
  "id": "GHSA-75xq-5h9v-w6px",
  "modified": "2026-05-14T20:49:03Z",
  "published": "2026-05-04T22:04:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-75xq-5h9v-w6px"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42258"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/6bf02aef7e0b5931010c36e377f79a71636b306b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/9db3e9d60bfb8f3735ea95015bf8a700f4af9cbb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/aec06996eb87a7e1bbcef1f9f8926e8add2b8c71"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42258.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap vulnerable to command Injection via unvalidated Symbol inputs"
}

GHSA-798G-QGW9-V4MF

Vulnerability from github – Published: 2024-12-06 18:30 – Updated: 2025-09-23 15:31
VLAI
Details

An improper neutralization of CRLF sequences ('CRLF Injection') vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow remote attackers to modify application data.

We have already fixed the vulnerability in the following versions: QTS 5.1.9.2954 build 20241120 and later QTS 5.2.2.2950 build 20241114 and later QuTS hero h5.1.9.2954 build 20241120 and later QuTS hero h5.2.2.2952 build 20241116 and later

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-48867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-06T17:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An improper neutralization of CRLF sequences (\u0027CRLF Injection\u0027) vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow remote attackers to modify application data.\n\nWe have already fixed the vulnerability in the following versions:\nQTS 5.1.9.2954 build 20241120 and later\nQTS 5.2.2.2950 build 20241114 and later\nQuTS hero h5.1.9.2954 build 20241120 and later\nQuTS hero h5.2.2.2952 build 20241116 and later",
  "id": "GHSA-798g-qgw9-v4mf",
  "modified": "2025-09-23T15:31:06Z",
  "published": "2024-12-06T18:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48867"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-24-49"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/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"
    }
  ]
}

GHSA-7CX2-G3H9-382P

Vulnerability from github – Published: 2026-06-16 21:02 – Updated: 2026-06-16 21:02
VLAI
Summary
Crawl4AI: Arbitrary file write (symlink/TOCTOU) plus log and webhook-header injection in Docker server
Details

Summary

Three backward-compatible hardening fixes in the Docker API server. The headline issue is an arbitrary file write via the screenshot/PDF output_path.

1. Arbitrary file write via output_path symlink / TOCTOU (primary)

POST /screenshot and POST /pdf accept an output_path constrained to ALLOWED_OUTPUT_DIR by validate_output_path. The 0.8.7 check was string-only: it did not resolve symlinks, so a symlinked path component inside the output directory could redirect the write outside the directory, and the final open() followed symlinks. On a deployment where the runtime user can write executable/cron locations this is an arbitrary-write to code-execution primitive. The API is unauthenticated by default.

Fix: validate_output_path now resolves the real path (symlinks) of the parent and re-checks containment, and the write uses O_NOFOLLOW (write_output_file). output_path remains supported.

2. CRLF log injection (CWE-117)

User-controlled URLs/errors reflected into log lines could embed CR/LF and forge additional log entries. Fix: a logging filter strips CR/LF/control characters from all records.

3. Webhook request-header injection (CWE-93/CWE-113)

User-supplied webhook headers were sent verbatim, allowing CRLF and hop-by-hop / sensitive header injection on the outbound webhook request. Fix: webhook headers are validated (name pattern, no control characters, deny Host/Content-Length/Transfer-Encoding/Authorization/Cookie/...), with early request-time rejection.

Impact

Arbitrary file write (potential code execution) for #1; log forging for #2; request smuggling / header injection on outbound webhooks for #3.

Workarounds

  • Upgrade to the patched version.
  • Enable authentication (CRAWL4AI_API_TOKEN).
  • Run the container with a read-only root filesystem.

Credits

Internal security audit (Crawl4AI maintainers).

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "crawl4ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-22",
      "CWE-59",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T21:02:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThree backward-compatible hardening fixes in the Docker API server. The headline issue is an arbitrary file write via the screenshot/PDF `output_path`.\n\n### 1. Arbitrary file write via output_path symlink / TOCTOU (primary)\n\n`POST /screenshot` and `POST /pdf` accept an `output_path` constrained to `ALLOWED_OUTPUT_DIR` by `validate_output_path`. The 0.8.7 check was string-only: it did not resolve symlinks, so a symlinked path component inside the output directory could redirect the write outside the directory, and the final `open()` followed symlinks. On a deployment where the runtime user can write executable/cron locations this is an arbitrary-write to code-execution primitive. The API is unauthenticated by default.\n\nFix: `validate_output_path` now resolves the real path (symlinks) of the parent and re-checks containment, and the write uses `O_NOFOLLOW` (`write_output_file`). `output_path` remains supported.\n\n### 2. CRLF log injection (CWE-117)\n\nUser-controlled URLs/errors reflected into log lines could embed CR/LF and forge additional log entries. Fix: a logging filter strips CR/LF/control characters from all records.\n\n### 3. Webhook request-header injection (CWE-93/CWE-113)\n\nUser-supplied webhook headers were sent verbatim, allowing CRLF and hop-by-hop / sensitive header injection on the outbound webhook request. Fix: webhook headers are validated (name pattern, no control characters, deny `Host`/`Content-Length`/`Transfer-Encoding`/`Authorization`/`Cookie`/...), with early request-time rejection.\n\n### Impact\n\nArbitrary file write (potential code execution) for #1; log forging for #2; request smuggling / header injection on outbound webhooks for #3.\n\n### Workarounds\n\n- Upgrade to the patched version.\n- Enable authentication (`CRAWL4AI_API_TOKEN`).\n- Run the container with a read-only root filesystem.\n\n### Credits\n\nInternal security audit (Crawl4AI maintainers).",
  "id": "GHSA-7cx2-g3h9-382p",
  "modified": "2026-06-16T21:02:19Z",
  "published": "2026-06-16T21:02:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai/security/advisories/GHSA-7cx2-g3h9-382p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai/issues/2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unclecode/crawl4ai/pull/3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/unclecode/crawl4ai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Crawl4AI: Arbitrary file write (symlink/TOCTOU) plus log and webhook-header injection in Docker server"
}

GHSA-7G2V-JJ9Q-G3RG

Vulnerability from github – Published: 2025-02-12 19:18 – Updated: 2025-11-04 00:32
VLAI
Summary
Possible Log Injection in Rack::CommonLogger
Details

Summary

Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs.

Details

When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env['REMOTE_USER'] and later be used by Rack::CommonLogger for logging purposes.

The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile.

Impact

Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files.

Mitigation

  • Update to the latest version of Rack.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
5.7 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1"
            },
            {
              "fixed": "3.1.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-12T19:18:35Z",
    "nvd_published_at": "2025-02-12T17:15:24Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`Rack::CommonLogger` can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs.\n\n## Details\n\nWhen a user provides the authorization credentials via `Rack::Auth::Basic`, if success, the username will be put in `env[\u0027REMOTE_USER\u0027]` and later be used by `Rack::CommonLogger` for logging purposes.\n\nThe issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile.\n\n## Impact\n\nAttackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files.\n\n## Mitigation\n\n- Update to the latest version of Rack.",
  "id": "GHSA-7g2v-jj9q-g3rg",
  "modified": "2025-11-04T00:32:20Z",
  "published": "2025-02-12T19:18:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-7g2v-jj9q-g3rg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/074ae244430cda05c27ca91cda699709cfb3ad8e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-25184.yml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00016.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Possible Log Injection in Rack::CommonLogger"
}

GHSA-847F-9342-265H

Vulnerability from github – Published: 2025-08-25 20:44 – Updated: 2025-11-03 21:34
VLAI
Summary
h2 allows HTTP Request Smuggling due to illegal characters in headers
Details

Summary

HTTP/2 request splitting vulnerability allows attackers to perform request smuggling attacks by injecting CRLF characters into headers. This occurs when servers downgrade HTTP/2 requests to HTTP/1.1 without properly validating header names/values, enabling attackers to manipulate request boundaries and bypass security controls.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "h2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-57804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-25T20:44:43Z",
    "nvd_published_at": "2025-08-25T21:15:37Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nHTTP/2 request splitting vulnerability allows attackers to perform request smuggling attacks by injecting CRLF characters into headers. This occurs when servers downgrade HTTP/2 requests to HTTP/1.1 without properly validating header names/values, enabling attackers to manipulate request boundaries and bypass security controls.",
  "id": "GHSA-847f-9342-265h",
  "modified": "2025-11-03T21:34:24Z",
  "published": "2025-08-25T20:44:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-hyper/h2/security/advisories/GHSA-847f-9342-265h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57804"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-hyper/h2/commit/035e9899f95e3709af098f578bfc3cd302298e3a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-hyper/h2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00004.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "h2 allows HTTP Request Smuggling due to illegal characters in headers"
}

GHSA-84G5-732R-258R

Vulnerability from github – Published: 2026-04-29 15:30 – Updated: 2026-06-06 09:31
VLAI
Details

Improper neutralization of CRLF sequences ('CRLF injection') vulnerability in TUBITAK BILGEM Software Technologies Research Institute Pardus allows Authentication Bypass.

This issue affects Pardus: from <=0.6.4 before 0.8.0.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-5140"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-29T14:16:19Z",
    "severity": "HIGH"
  },
  "details": "Improper neutralization of CRLF sequences (\u0027CRLF injection\u0027) vulnerability in TUBITAK BILGEM Software Technologies Research Institute Pardus allows Authentication Bypass.\n\nThis issue affects Pardus: from \u003c=0.6.4 before 0.8.0.",
  "id": "GHSA-84g5-732r-258r",
  "modified": "2026-06-06T09:31:16Z",
  "published": "2026-04-29T15:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5140"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0131"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-26-0131"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84H7-RJJ3-6JX4

Vulnerability from github – Published: 2025-12-15 23:28 – Updated: 2025-12-20 02:30
VLAI
Summary
Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder
Details

Summary

The io.netty.handler.codec.http.HttpRequestEncoder CRLF injection with the request uri when constructing a request. This leads to request smuggling when HttpRequestEncoder is used without proper sanitization of the uri.

Details

The HttpRequestEncoder simply UTF8 encodes the uri without sanitization (buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);)

The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.

PoC

Simple reproducer:

public static void main(String[] args) {

  EmbeddedChannel client = new EmbeddedChannel();
  client.pipeline().addLast(new HttpClientCodec());

  EmbeddedChannel server = new EmbeddedChannel();
  server.pipeline().addLast(new HttpServerCodec());
  server.pipeline().addLast(new ChannelInboundHandlerAdapter() {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
      System.out.println("Processing msg " + msg);
    }
  });

  DefaultHttpRequest request = new DefaultHttpRequest(
    HttpVersion.HTTP_1_1,
    HttpMethod.GET,
    "/s1 HTTP/1.1\r\n" +
      "\r\n" +
      "POST /s2 HTTP/1.1\r\n" +
      "content-length: 11\r\n\r\n" +
      "Hello World" +
      "GET /s1"
  );
  client.writeAndFlush(request);
  ByteBuf tmp;
  while ((tmp = client.readOutbound()) != null) {
    server.writeInbound(tmp);
  }
}

Impact

Any application / framework using HttpRequestEncoder can be subject to be abused to perform request smuggling using CRLF injection.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.8.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.129.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67735"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-15T23:28:49Z",
    "nvd_published_at": "2025-12-16T01:15:52Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri.\n\n### Details\n\nThe `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`)\n\nThe default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.\n\n### PoC\n\nSimple reproducer:\n\n```java\npublic static void main(String[] args) {\n\n  EmbeddedChannel client = new EmbeddedChannel();\n  client.pipeline().addLast(new HttpClientCodec());\n\n  EmbeddedChannel server = new EmbeddedChannel();\n  server.pipeline().addLast(new HttpServerCodec());\n  server.pipeline().addLast(new ChannelInboundHandlerAdapter() {\n    @Override\n    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {\n      System.out.println(\"Processing msg \" + msg);\n    }\n  });\n\n  DefaultHttpRequest request = new DefaultHttpRequest(\n    HttpVersion.HTTP_1_1,\n    HttpMethod.GET,\n    \"/s1 HTTP/1.1\\r\\n\" +\n      \"\\r\\n\" +\n      \"POST /s2 HTTP/1.1\\r\\n\" +\n      \"content-length: 11\\r\\n\\r\\n\" +\n      \"Hello World\" +\n      \"GET /s1\"\n  );\n  client.writeAndFlush(request);\n  ByteBuf tmp;\n  while ((tmp = client.readOutbound()) != null) {\n    server.writeInbound(tmp);\n  }\n}\n```\n\n### Impact\n\nAny application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection.",
  "id": "GHSA-84h7-rjj3-6jx4",
  "modified": "2025-12-20T02:30:14Z",
  "published": "2025-12-15T23:28:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67735"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/77e81f1e5944d98b3acf887d3aa443b252752e94"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder"
}

GHSA-84HM-WFH8-C5PG

Vulnerability from github – Published: 2026-05-05 22:17 – Updated: 2026-05-13 16:27
VLAI
Summary
sse-channel: SSE Injection via unsanitized event fields
Details

Impact

Implementations that allows user-provided values to be passed to event, retry or id fields would be susceptible to event spoofing, where an attacker could inject arbitrary messages into the stream.

  • Event Spoofing: Attacker can inject arbitrary SSE events into the stream
  • Client-side Manipulation: Injected events can trigger unintended behavior in frontend JavaScript EventSource listeners
  • Data Integrity: Consumers of the SSE stream cannot distinguish injected events from legitimate ones

Patches

Patch available in v4.0.1.

Workarounds

Do not allow user data to control event, retry or id fields, and if you must - sanitize the input before passing it to sse-channel, stripping any newlines.

Resources

https://github.com/rexxars/sse-channel/issues/42

Severity
6.6 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.0.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "sse-channel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T22:17:02Z",
    "nvd_published_at": "2026-05-12T20:16:42Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nImplementations that allows user-provided values to be passed to `event`, `retry` or `id` fields would be susceptible to event spoofing, where an attacker could inject arbitrary messages into the stream.\n\n- **Event Spoofing:** Attacker can inject arbitrary SSE events into the stream\n- **Client-side Manipulation:** Injected events can trigger unintended behavior in frontend JavaScript EventSource listeners\n- **Data Integrity:** Consumers of the SSE stream cannot distinguish injected events from legitimate ones\n\n### Patches\nPatch available in v4.0.1.\n\n### Workarounds\nDo not allow user data to control `event`, `retry` or `id` fields, and if you must - sanitize the input before passing it to `sse-channel`, stripping any newlines. \n\n### Resources\n\nhttps://github.com/rexxars/sse-channel/issues/42",
  "id": "GHSA-84hm-wfh8-c5pg",
  "modified": "2026-05-13T16:27:28Z",
  "published": "2026-05-05T22:17:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rexxars/sse-channel/security/advisories/GHSA-84hm-wfh8-c5pg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rexxars/sse-channel/issues/42"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rexxars/sse-channel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "sse-channel: SSE Injection via unsanitized event fields"
}

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.

Severity
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}
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.

← Back to the CWE list