Development record
launch's structural deny is applied per path segment and case-insensitively, so a nested or case-varied denied namespace cannot enter the payload (GitHub mirror: #335).
issueresolvedcriticaliss-2608270735428304
launch's structural deny is applied per path segment and case-insensitively, so a nested or case-varied denied namespace cannot enter the payload (GitHub mirror: #335).
Frontmatter
| id | iss-2608270735428304 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | critical |
.abcd/work/issues/resolved/iss-2608270735428304-launch-s-structural-deny-is-applied-per.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609012035113186GHSA-g2v7-wfmv-v28r (CWE-693): launch's structural deny was applied to the first path segment only, so a nested or case-varied denied namespace could enter the release payload. Fixed before this run by 30f62e82 (fix(launch): close nested/case-fold deny bypass and unscanned-payload gap), shipped in v0.6.7; the class record is resolved/iss-2608270735428304 (GitHub mirror #335), which does not name the GHSA id. This record binds the advisory id to its fixing commit so an advisory-keyed search hits. Evidence at v0.7.0: internal/core/launch/bundle.go segmentDenied and pathContainsDeniedSegment; tests TestNestedDeniedNamespaceExcluded and TestCaseFoldDeniedNamespaceExcluded in bundle_denyseg_test.go.