A county ticket system passes unsanitized user fields into a shell command that generates PDFs. Which vulnerability class does this describe?
Select an answer to reveal the explanation.
Short Explanation
Handing a stranger the microphone to the shell is a bad karaoke night for the server. When user text lands inside OS commands, that is command injection — often critical. Name the class and impact; skip payload shopping lists.
Full Explanation
OS command injection occurs when untrusted input influences operating-system commands. A county ticket system that passes unsanitized user fields into a shell command generating PDFs places resident-controlled data on the wrong side of a process boundary—enabling command-execution impact classes against the host that processes civic tickets.
DOM-based open redirect is a navigation issue, not shell influence. IDOR on ticket numbers is object authorization, a different class. Stored XSS in the subject alone does not describe shelling out with user fields.
Exam caveat: prefer APIs that accept arguments as data (no shell), not string-built commands; if a shell is unavoidable, allowlist strictly. CPTS command-injection findings should stress unsafe process invocation in municipal document pipelines.
Operational check: identify the PDF generation call path, replace shell concatenation with safe libraries/argument arrays, fuzz only within RoE with non-destructive probes, and verify user ticket fields no longer reach a shell. Ticket-to-PDF pipelines for counties should use library APIs with argument arrays; add security tests that fail if shell metacharacters ever reach a shell. PDF microservices should run with least privilege so residual injection cannot become full host control.