Add CWE-94 eval/exec code-injection test case - #170
Conversation
|
Submitted per the uGig listing ("I will pay .25 per malicious submission"): a new CWE-94 code-injection test case with 3 VULNERABLE: markers and 1 SAFE: counterpart, catalog regenerated. All CI checks (Socket Security) pass. Happy to add more variants (deserialisation, SSTI, command injection) or adjust the safe counterpart on request. |
|
Heads-up for the payout pipeline: the CoinPayPortal workflow is failing for every /coinpay command in this repo (runs #11-#16) because the profullstack/coinpaybot@v0 action.yml embeds a secrets-context expression inside an input description, and GitHub errors while loading the action ( |
Test Case Submission
docs/CONTRIBUTING.mdif False:)@id,@test-case,@cwe,@severity,@language,@expected-detection,@description,@safe-guard,@detection-target)VULNERABLE:and correct-code lines withSAFE:scripts/generate-catalog.py) and committed the resultDetails
eval()/exec()on attacker-controlled inputeval()/exec()on request-derived data is a direct-to-RCE sink, but scannersfrequently miss it when the taint passes through
str.replace,base64.b64decode, orrequest.form. This caseadds three vulnerable variants plus a safe counterpart using
ast.literal_evalwith an operator whitelist, sorecall and false-positive control can both be measured.
Safety statement
Every payload sits inside
if False:blocks and is unreachable dead code at runtime. There are no imports ofexecutable modules, no hosts, no credentials, no disk or socket I/O, and no dependency manifests. If the guard
were removed, the worst outcome would still be that
evalof a non-existent expression cannot run.