Adversarial fuzz worker

boundary-probe

Session e3confirm-20260729-0001 · Worker boundary-probe

FAIL

Fuzz run descriptionIterationsPassResult
Malformed files, invalid var-file boundaries, path confinement, and stable diagnostics (frontmatter target) 99 94/99 FAIL

Inputs exercised

CaseTemplate / inputOutcome
FUZZ-001FR-7b: exit 3 for usage/configuration/contract error. ERR_CONFIG_READ is a documented ConfigError-family code, so it should exit 3.confirmed product bug (3 reproductions): Exits 2 (validation/render family) with ERR_CONFIG_READ, while the equivalent invalid-UTF-8 --var-file failure exits 3. Exit-code family disagrees with the diagnostic family.
FUZZ-002A security-relevant confinement refusal must not be reported with a not-found code; the engine already has a dedicated ERR_INCLUDE_ESCAPE for the identical condition during includeconfirmed product bug (3 reproductions): Refused correctly (no read occurs, exit 3) but with ERR_RESOLVE_NOT_FOUND and message 'template path escapes configured roots', i.e. an escape reported under a not-found code. Confirmed for ../ traversal, absolute path,
FUZZ-003No include is in play for a top-level --file, and the sibling nonexistent-path case correctly returns ERR_RESOLVE_NOT_FOUND with exit 3.confirmed product bug (3 reproductions): Returns ERR_INCLUDE_NOT_FOUND 'include file not found: <dir>' with exit 2; the nonexistent-path sibling returns ERR_RESOLVE_NOT_FOUND with exit 3. Both code and exit family are inconsistent for the same argument.
FUZZ-004FR-8: diagnostics must include source file path, line and column when available. The equivalent `required_variables: [x]` declaration proves line/column ARE computable for the sameconfirmed product bug (3 reproductions): Both styles give code ERR_VAL_MISSING_REQUIRED, exit 2, and the same message naming x. But `required_variables` yields line=3 column=5, while `variables: {x: {required: true}}` yields line=null column=null. (Coordinator
FUZZ-005FR-8: diagnostics must include path, line and column when available. Human-mode output proves the location is known.confirmed product bug (3 reproductions): Human mode prints 'did not find expected key at line 3 column 2'. The --json diagnostic for the identical failure carries ERR_CONFIG_PARSE with path=null, line=null, column=null. Machine consumers get strictly less infor

Findings

FUZZ-001

Minimal template / frontmatter
\xa0
Input
(none)
Expected
FR-7b: exit 3 for usage/configuration/contract error. ERR_CONFIG_READ is a documented ConfigError-family code, so it should exit 3.
Observed
Exits 2 (validation/render family) with ERR_CONFIG_READ, while the equivalent invalid-UTF-8 --var-file failure exits 3. Exit-code family disagrees with the diagnostic family.
Requirement / ADR
No requirement/ADR currently traces this exact behavior; classified via the adversarial-fuzzing oracle rules (stable diagnostic/top-level boundary).
Requirement / ADR follow-up
Map ERR_CONFIG_READ to exit 3 per FR-7b.
Root cause
See observed_result; coordinator-established root cause recorded in campaign-report.json.
Recommended fix
Map ERR_CONFIG_READ to exit 3 per FR-7b.

FUZZ-002

Minimal template / frontmatter
a file existing one level above --root
Input
(none)
Expected
A security-relevant confinement refusal must not be reported with a not-found code; the engine already has a dedicated ERR_INCLUDE_ESCAPE for the identical condition during include expansion.
Observed
Refused correctly (no read occurs, exit 3) but with ERR_RESOLVE_NOT_FOUND and message 'template path escapes configured roots', i.e. an escape reported under a not-found code. Confirmed for ../ traversal, absolute path, and symlink-outside-root.
Requirement / ADR
No confinement bypass: every escape attempt was correctly refused and nothing outside --root was read. This is a diagnostic-accuracy defect only.
Requirement / ADR follow-up
Introduce/reuse an escape-specific code for top-level --file confinement refusals; register it in the error-code registry.
Root cause
See observed_result; coordinator-established root cause recorded in campaign-report.json.
Recommended fix
Introduce/reuse an escape-specific code for top-level --file confinement refusals; register it in the error-code registry.

FUZZ-003

Minimal template / frontmatter
an empty directory passed as --file
Input
(none)
Expected
No include is in play for a top-level --file, and the sibling nonexistent-path case correctly returns ERR_RESOLVE_NOT_FOUND with exit 3.
Observed
Returns ERR_INCLUDE_NOT_FOUND 'include file not found: <dir>' with exit 2; the nonexistent-path sibling returns ERR_RESOLVE_NOT_FOUND with exit 3. Both code and exit family are inconsistent for the same argument.
Requirement / ADR
No requirement/ADR currently traces this exact behavior; classified via the adversarial-fuzzing oracle rules (stable diagnostic/top-level boundary).
Requirement / ADR follow-up
Return ERR_RESOLVE_NOT_FOUND (or a not-a-file code) with exit 3 when --file names a directory.
Root cause
See observed_result; coordinator-established root cause recorded in campaign-report.json.
Recommended fix
Return ERR_RESOLVE_NOT_FOUND (or a not-a-file code) with exit 3 when --file names a directory.

FUZZ-004

Minimal template / frontmatter
--- variables: x: required: true --- {{x}}
Input
(none)
Expected
FR-8: diagnostics must include source file path, line and column when available. The equivalent `required_variables: [x]` declaration proves line/column ARE computable for the same file, so the two declaration styles must yield identically shaped diagnostics.
Observed
Both styles give code ERR_VAL_MISSING_REQUIRED, exit 2, and the same message naming x. But `required_variables` yields line=3 column=5, while `variables: {x: {required: true}}` yields line=null column=null. (Coordinator correction to the worker's report: `path` IS populated in both styles; only line/column are lost.)
Requirement / ADR
The `variables:` map is the feature ADDED by cd54074. Pre-fix it was ignored entirely, so this incomplete diagnostic shape ships WITH the fix rather than predating it. This is the only finding attributable to cd54074 itself.
Requirement / ADR follow-up
Thread line/column into ERR_VAL_MISSING_REQUIRED for the `variables:` declaration style so both styles match. Highest priority: this gap shipped with cd54074.
Root cause
The `variables:` map is the feature ADDED by cd54074. Pre-fix it was ignored entirely, so this incomplete diagnostic shape ships WITH the fix rather than predating it. This is the only finding attributable to cd54074 itself.
Recommended fix
Thread line/column into ERR_VAL_MISSING_REQUIRED for the `variables:` declaration style so both styles match. Highest priority: this gap shipped with cd54074.

FUZZ-005

Minimal template / frontmatter
--- foo: bar: 1 baz: 2 --- body
Input
(none)
Expected
FR-8: diagnostics must include path, line and column when available. Human-mode output proves the location is known.
Observed
Human mode prints 'did not find expected key at line 3 column 2'. The --json diagnostic for the identical failure carries ERR_CONFIG_PARSE with path=null, line=null, column=null. Machine consumers get strictly less information than humans for the same failure. Reproduced across tab indentation, unclosed quote, unclosed flow map, and non-map frontmatter shapes.
Requirement / ADR
No requirement/ADR currently traces this exact behavior; classified via the adversarial-fuzzing oracle rules (stable diagnostic/top-level boundary).
Requirement / ADR follow-up
Propagate serde_yaml::Error::location() and the template path into ConfigError -> Diagnostic so --json matches human output.
Root cause
See observed_result; coordinator-established root cause recorded in campaign-report.json.
Recommended fix
Propagate serde_yaml::Error::location() and the template path into ConfigError -> Diagnostic so --json matches human output.