Hardening: ContentRewriter mangles //<configured-host> path segments; rewriter drops non-default ports #14

New issue

Closed

opened 2026-10-15 22:38:57 -07:00 by eric · 0 comments

eric commented

2026-10-15 22:38:57 -07:00

Owner

Type: hardening / correctness. Found by security audit run 3 (commit 01195c8) during URL-parser fuzzing (no redirect to an unconfigured host was found in 21k cases).

What happens

The ContentRewriter pattern (src/Rewrite/ContentRewriter.php:46) has no left boundary before the optional scheme and //host. A same-site link whose path contains //<configured-host>/, e.g. http://example.com//example.com/x, is rewritten to https://www.example.comhttps://www.example.com/x (a broken, non-resolvable host).
UrlRewriter::buildTail (src/Rewrite/UrlRewriter.php:82-87) drops the port and userinfo, so https://example.com:8443/x becomes https://<current>/x. It stays on a configured host, but configured hosts served on non-default ports break.

Suggested fix

Anchor the content match with a lookbehind such as (?<![\w.:/-]) before the optional scheme group (or require a preceding quote, =, whitespace or start of string). Carry $parts['port'] through only when the configured host entry declares a port. Regression case: rewrite('<a href="http://example.com//example.com/x">') keeps the path segment intact.

**Type:** hardening / correctness. Found by security audit run 3 (commit `01195c8`) during URL-parser fuzzing (no redirect to an unconfigured host was found in 21k cases). ## What happens - The `ContentRewriter` pattern (`src/Rewrite/ContentRewriter.php:46`) has no left boundary before the optional scheme and `//host`. A same-site link whose path contains `//<configured-host>/`, e.g. `http://example.com//example.com/x`, is rewritten to `https://www.example.comhttps://www.example.com/x` (a broken, non-resolvable host). - `UrlRewriter::buildTail` (`src/Rewrite/UrlRewriter.php:82-87`) drops the port and userinfo, so `https://example.com:8443/x` becomes `https://<current>/x`. It stays on a configured host, but configured hosts served on non-default ports break. ## Suggested fix Anchor the content match with a lookbehind such as `(?<![\w.:/-])` before the optional scheme group (or require a preceding quote, `=`, whitespace or start of string). Carry `$parts['port']` through only when the configured host entry declares a port. Regression case: `rewrite('<a href="http://example.com//example.com/x">')` keeps the path segment intact.

eric added the

enhancement

security

labels

2026-10-15 22:38:57 -07:00

eric referenced this issue from a commit

2026-10-16 13:00:48 -07:00

fix: anchor inline host matches to the start of a link

eric closed this issue

2026-10-16 13:00:48 -07:00