potiuk opened a new issue, #59821: URL: https://github.com/apache/airflow/issues/59821
### Discussed in https://github.com/apache/airflow/discussions/59820 <div type='discussions-op-text'> <sup>Originally posted by **ronak-sirwani** December 26, 2025</sup> Context: I recently scanned our Airflow 3.0.6 deployment (using the official apache/airflow:slim-3.0.6-python3.12 image) and encountered a critical severity vulnerability flagged by Snyk in [email protected]. The Finding: The scanner pointed to this path: /home/airflow/.local/lib/python3.12/site-packages/airflow/api_fastapi/auth/managers/simple/ui/package.json Upon investigation inside the image, I found: - airlfow UI build Manifests: A package.json and package-lock.json (pinning the vulnerable [email protected]) exist in this directory. - No Code: The node_modules directory is correctly stripped, so the vulnerable code itself is missing. - Conflicting Lockfiles: A pnpm-lock.yaml is also present, which pins the safe version 4.0.4. I noticed that while the 'main' branch has updated package-lock.json to the secure form-data version, the underlying issue remains: why do we ship these files at all? I've little knowledge of the frontend build, but from a runtime perspective, these manifests appear to be "ghost" artifacts. Since node_modules are stripped and the UI is pre-compiled, keeping these files in the production image—even if patched—leaves the door open for future false positives whenever a frontend dependency (that isn't even installed) gets flagged. I am currently planning to patch our internal Docker builds by deleting package.json and package-lock.json to satisfy our security scanners, but I want to make sure I’m not breaking anything critical. Is there any specific runtime reason why these files must remain in the production image? Any insights or validation would be greatly appreciated!</div> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
