T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/edit.py:220
- Finding
- fal.ai Safety Checker Explicitly Disabled During Image Editing## Vulnerability Details **File Location**: `scripts/edit.py`, lines 220–244 **Vulnerability Type**: Provider-side safety control disabled by default **Risk Level**: Medium ```python arguments = { "prompt": prompt, "image_size": {"width": dims["width"], "height": dims["height"]}, "num_images": 1, "max_images": 1, "enable_safety_checker": False, "enhance_prompt_mode": "standard", "sync_mode": True, "image_urls": [data_uri], } if seed is not None: arguments["seed"] = seed url = f"https://fal.run/{model_id}" payload = json.dumps(arguments).encode() req = urllib.request.Request( url, data=payload, headers={ "Authorization": f"Key {api_key}", "Content-Type": "application/json", }, ) ``` ### Technical Analysis Every fal.ai image-editing request explicitly sets `enable_safety_checker` to `False`. Disabling this safeguard is not necessary for the declared image-editing functionality and is not disclosed in `SKILL.md`, `README.md`, or `references/fal.md`. The setting is unconditional and cannot be overridden through the command-line interface. Consequently, even ordinary invocations silently request that fal.ai process the supplied prompt and image without its optional content-safety checker. This differs from the OpenAI and Gemini paths, which retain provider filtering and handle safety-related rejection responses. Base64 encoding of the selected image and its transmission to fal.ai are functionally necessary for image-to-image editing and do not, by themselves, constitute covert exfiltration. The confirmed issue is the unnecessary disabling of the provider-side safeguard. ### Attack Path 1. An attacker or user supplies an image and an unsafe editing instruction. 2. The Skill is invoked with `python scripts/edit.py --provider fal --image INPUT --prompt PROMPT`. 3. The script reads and Base64-encodes the explicitly selected image. ...[truncated 840 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the `enable_safety_checker` field so the provider's secure default applies, or explicitly set it to `True`. 2. If disabling the checker is an essential supported capability, require a dedicated opt-in command-line flag rather than disabling it unconditionally. 3. Require explicit user confirmation before honoring such an opt-in and clearly explain the policy and safety implications. 4. Document the setting in `SKILL.md`, `README.md`, and `references/fal.md`. 5. Add tests verifying that normal fal.ai edit requests enable or preserve safety filtering. 6. Reject unsafe combinations by default and avoid automatically retrying requests in ways intended to bypass provider safety decisions.
