# Multiple vulnerabilities related to PCRE functions (already fixed)

PCRE's \K with lookahead yields offsets where start>end, causing heap overflow/memcpy underflow in PHP's preg_match/preg_replace/preg_split.

- Payout: hidden
- Severity: high
- Program: Internet Bug Bounty
- Found by: mongo
- Disclosed: 2019-11-12
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/141839
- Library page: https://bugbountylibrary.com/r/h1%3A141839
- Tags: area:oss domain:oss impact:dos impact:rce kind:bounty platform:hackerone sev:high tech:php technique:source-review vuln:dos vuln:memory-corruption

**Target:** PHP ext/pcre (pcre_exec offset handling)
**Root cause:** pcre_exec() can return offsets where start > end (e.g. via \K inside a lookahead), violating the invariant assumed throughout PHP's PCRE wrappers, which compute lengths as end-start without validation.
**Steps:**
1. Use regex `/(?=xyz\K)/` against subject `aaaaxyzaaaa`.
2. Call `preg_match($regex, $subject, $matches)` (also preg_replace with `\0`, preg_split).
3. Observe SIGSEGV in memcpy with __len=18446744073709551613 (negative length) inside php_pcre_get_substring_list.
**How found:** Reasoned about the pcre_exec offset contract (start<=end) and realized certain regex constructs like \K inside lookahead break it; then audited PHP's PCRE call sites and found none validate the offsets.
**Exploitation:** Not demonstrated beyond crash; author notes arbitrary code execution via the heap overflow might be possible but non-trivial. Memory exhaustion reachable via preg_split.
**Insight:** When a library returns paired offsets/lengths, hunt for regex or parser constructs (\K, lookarounds, zero-width assertions) that violate the start<=end invariant, then check every consumer that computes end-start without validation.