Towards the Systematic Testing of Regular Expression Engines

TL;DR

This paper presents ReTest, a systematic testing framework for regex engines that combines grammar-aware fuzzing and metamorphic testing to improve bug detection and coverage.

Contribution

The work introduces ReTest, a novel framework that enhances regex engine testing through grammar-aware fuzzing and dialect-independent metamorphic testing.

Findings

ReTest achieves 3x higher edge coverage than existing fuzzers.

Identified three new memory safety defects in PCRE.

Analyzed 1,007 regex engine bugs and 156 CVEs.

Abstract

Software engineers use regular expressions (regexes) across a wide range of domains and tasks. To support regexes, software projects must integrate a regex engine, whether provided natively by the language runtime (e.g., Python's re) or included as an external dependency (e.g., PCRE). However, these engines may contain bugs and introduce vulnerabilities. A common strategy for testing regex engines involves differential testing -- comparing outputs across different implementations. However, this approach is concerning because regex syntax and semantics vary significantly between dialects (e.g., POSIX vs. PCRE). Fuzzing is also utilized to ease testing of feature-rich regex implementations to expose defects, but naive byte-level mutations generate syntactically invalid inputs that exercise only parsing logic, not matching internals. In this work, we describe our progress towards ReTest, a framework that systematically tests regular expression engines by combining grammar-aware fuzzing for high code coverage with metamorphic testing to generate dialect-independent test oracles. So far, we have surveyed testing practices across 22 regex engines, analyzed 1,007 regex engine bugs and 156 CVEs to characterize failure modes, and curated 16 metamorphic relations for regexes derived from Kleene algebra. Our preliminary evaluation on PCRE shows that ReTest achieves 3x higher edge coverage than existing fuzzing approaches and has identified three new memory safety defects. We conclude by describing our next steps toward our ultimate goal: helping regex engine developers identify bugs without depending on a consistent cross-implementation standard.