[Kirtan-pc]

Summary

This PR fixes Issue #1233: ml-service/app.py never sets app.config["MAX_CONTENT_LENGTH"], so Flask buffers unbounded request bodies. POST /predict-image calls Image.open() on attacker-controlled bytes; a crafted multi-GB upload or a tiny decompression bomb exhausts RAM/CPU and can OOM-kill the gunicorn workers.

Changes

• ml-service/app.py (lines 16-22): Set app.config["MAX_CONTENT_LENGTH"] to ML_MAX_UPLOAD_MB (default 10 MB, configurable via env var) so Flask rejects oversized request bodies before buffering them.
• ml-service/app.py (line 22): Set Image.MAX_IMAGE_PIXELS = 100_000_000 (100 megapixels) so Pillow raises DecompressionBombError before fully decoding a malicious image.
• ml-service/app.py (lines 238-243): Added @app.errorhandler(413) returning structured JSON ({"error": "Payload too large", "details": "..."}) instead of Flask's default HTML error page.
• ml-service/app.py (lines 284-288): Catch DecompressionBombError in predict_image and return a 413 with a clear message including the pixel limit.
• ml-service/app.py (line 12): Import DecompressionBombError from PIL.

Fixes #1233

Copilot Review Feedback

Other suggestions were evaluated but intentionally left unchanged because they are pre-existing issues outside the scope of Issue #1233:

Comment	Verdict	Reason
Add per-endpoint MAX_CONTENT_LENGTH overrides	Out of scope	Flask does not natively support per-route content-length limits; would require custom middleware beyond a targeted fix
Stream image processing instead of buffering	Out of scope	Pre-existing architecture gap; Pillow's Image.open() on a stream still reads the full image for dimension validation
Add virus/malware scanning for uploads	Out of scope	Pre-existing feature gap; introduces new infrastructure dependency beyond a targeted DoS fix

[vercel]

@Kirtan-pc is attempting to deploy a commit to the Nitya Gosain's projects Team on Vercel.

A member of the Team first needs to authorize it.