Potential fix for code scanning alert no. 2: Uncontrolled command line#15
Merged
Potential fix for code scanning alert no. 2: Uncontrolled command line#15
Conversation
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
sys-vdms
approved these changes
Jan 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Potential fix for https://github.com/IntelLabs/Video-Curation-Sample/security/code-scanning/2
In general, to fix this, we should validate and constrain the user-controlled
videoparameter before using it to build theffprobecommand. The path joining is already done safely, but we should additionally ensure that thevideoargument is a “safe” relative file name (no path separators, not empty, optionally with a required extension). That way, even thoughPopenis called withshell=False, we explicitly restrict what can be passed toffprobe.The best targeted fix without changing existing behavior is to introduce a small helper function in
video/utils.py(wheresafely_join_pathalready lives) that validates the filename portion, and then use it inInfoHandler.getbefore passingvideodown to_get_info. The helper can reject values that contain path separators or are empty/whitespace. Inget, we call this validator right after reading thevideoargument; if validation fails, we return a 400 error. The rest of the logic, including theffprobeinvocation and response format, remains unchanged.Concretely:
video/utils.py, add a new functionvalidate_video_name(name: str) -> strthat:nameis a string./oros.sep(to ensure it’s just a file name, not a path).video/info.py, importvalidate_video_namefromutils, and inInfoHandler.get:validate_video_name(video)inside atryblock.ValueError, respond with HTTP 400 and stop processing.video(possibly normalized) for the existing checks and for_get_info.This keeps the behavior for valid inputs the same, but ensures that only sanitized, well-formed file names reach the
Popencommand.Suggested fixes powered by Copilot Autofix. Review carefully before merging.