Security audit
Security checks for vulnerabilities and agentic risk
ClawScan marked this skill suspicious because setup instructions reportedly include quick-install commands that publish an unauthenticated API, and use mutable container image tags; confidence is medium and coverage is incomplete.
Review the setup instructions before installing. Avoid exposing the API without authentication, and verify the container image source and pin a trusted digest before deployment. Treat this verdict as a reason for caution, not as proof of malicious intent; scanner coverage was partial (66.7%), so the evidence is incomplete.
references/setup.mdQuick-install commands publish the API without authentication
An attacker can access staged media and invoke processing or management operations, compromising media confidentiality and consuming or disrupting the instance's resources.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Probe a video (stage it first, then reference by path).
curl -s -X PUT --data-binary @clip.mp4 \
-H "Authorization: Bearer $FLICKIES_AUTH_TOKEN" \
"$FLICKIES_URL/v1/files/uploads/clip.mp4"
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
-d '{"file_path": "uploads/clip.mp4"}' | jq
# Trim seconds 5–12, write the result under FILES_DIR, download it.
curl -s -X POST "$FLICKIES_URL/v1/video/trim" \
-H "Content-Type: application/json" \
-d '{
"file_path": "uploads/clip.mp4",
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"start_sec": 5, "end_sec": 12, "precise": true,
"output_path": "out/clip-trimmed.mp4"
}' | jq
curl -s "$FLICKIES_URL/v1/files/out/clip-trimmed.mp4" --output clip-trimmed.mp4
# Lipsync a face to an audio track (LatentSync, commercial-safe default, CUDA).
curl -s -X POST "$FLICKIES_URL/v1/video/lipsync" \
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
ffprobe metadata. Input via file_path / file_url; no output fields.
curl -s -X POST "$FLICKIES_URL/v1/video/info" \
-H "Content-Type: application/json" \
-d '{"file_path": "uploads/clip.mp4"}' | jq
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
1. Submit: POST with async_job: true. The server stages the result under jobs/ in FILES_DIR and ignores output_path / output_url. Lipsync and restore load their engine before answering, so a cold engine still holds this request. Response is 202:
JOB=$(curl -s -X POST "$FLICKIES_URL/v1/video/lipsync" \
-H "Content-Type: application/json" \
-d '{
"face_url": "https://example.com/face.mp4",
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
PATH_ON_SERVER=$(curl -s "$FLICKIES_URL/v1/jobs/$JOB" | jq -r .result.path)
curl -s "$FLICKIES_URL/v1/files/$PATH_ON_SERVER" --output result.mp4
Webhook alternative — pass webhook_url on the async submit and the server POSTs the final job state ({job_id, status, result, error}) to that URL on completion instead of making you poll:
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
}' | jq
curl -s -X POST "$FLICKIES_URL/v1/video/restore"
-H "Content-Type: application/json"
-d '{"file_path": "out/talking.mp4", "output_path": "out/talking-restored.mp4"}' | jq
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -s -X PUT --data-binary @raw.mp4 "$FLICKIES_URL/v1/files/uploads/raw.mp4"
curl -s -X POST "$FLICKIES_URL/v1/video/scale" \
-H "Content-Type: application/json" \
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
-H "Content-Type: application/json" \
-d '{"file_path":"uploads/raw.mp4","width":1280,"height":720,"output_path":"out/720p.mp4"}' | jq
curl -s -X POST "$FLICKIES_URL/v1/video/transcode" \
-H "Content-Type: application/json" \
-d '{"file_path":"uploads/raw.mp4","output_format":"gif","fps":12,"gif_options":{"width":480},"output_path":"out/raw.gif"}' \
--fail | jq
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -s -X POST "$FLICKIES_URL/v1/video/concat" \
-H "Content-Type: application/json" \
-d '{
"inputs_urls": ["https://ex.com/a.mp4","https://ex.com/b.mp4"],
The scanner incorrectly identifies 'docker run -d' as the image reference; the complete command uses psyb0t/flickies:latest. Although explicitly tagged, this image is not digest-pinned, so a changed or compromised upstream tag could introduce unreviewed code with access to the writable /data mount.
The complete CUDA command references psyb0t/flickies:latest-cuda, not an image named 'docker run -d'; the literal missing-tag diagnosis is inaccurate. The mutable tag nevertheless allows unreviewed image changes, and a compromised image would receive access to the mounted data and exposed GPU devices.
This multiline command uses the explicit but mutable latest-cuda tag, so the scanner's claim that no tag exists is incorrect. Digest pinning is still absent, allowing an upstream image replacement to execute with writable data and GPU access; the non-commercial engine gate does not mitigate this supply-chain risk.
The authenticated deployment uses latest-cuda, which is tagged but not immutable. A compromised replacement image could read the bearer token supplied through its environment and access mounted data, so enabling API authentication does not resolve the image-integrity weakness.
The prefetch example references latest-cuda explicitly, contrary to the scanner's missing-tag wording, but does not pin its content. Prefetching selected models does not prevent a changed or compromised container image from executing with access to the persistent data mount.
The keep-resident example uses the mutable latest-cuda tag rather than an immutable digest. An upstream replacement could therefore introduce unreviewed code when the image is obtained, and the idle-unload setting provides no protection against that risk.
This example has an explicit latest-cuda tag, but it remains mutable and unpinned. A compromised image could access both the mounted data and the webhook signing secret in its environment, potentially enabling forged callbacks.
The loopback-only example uses psyb0t/flickies:latest, so it is tagged but not digest-pinned. Loopback binding reduces inbound network exposure, but does not stop a compromised upstream image from running and accessing the writable host data directory.
The custom-registry deployment explicitly references latest-cuda, but its content can change because no digest is specified. Mounting the engine registry read-only protects that file against modification through the mount; it does not establish image integrity or protect the writable data mount from a compromised image.
The pull command explicitly includes :latest, making the scanner's missing-tag description inaccurate, but the update target is mutable. Pulling does not execute the image or replace a running container by itself; the risk materializes when a subsequently created container runs an unreviewed or compromised image.
The CUDA update command includes :latest-cuda, but that tag can be reassigned and provides no immutable version guarantee. The pull itself does not execute code, yet subsequent deployment could run a compromised replacement with the data and GPU access shown in the setup examples.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
)"
submit_resp="$(
curl -s "${auth_args[@]}" \
-H "Content-Type: application/json" \
-X POST "$FLICKIES_URL/v1/video/${endpoint}" \
-d "$submit_body"