^{Originally posted by ronak-sirwani December 26, 2025}
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 form-data@4.0.1.

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 form-data@4.0.1) 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!