Security audit
Security checks for vulnerabilities and agentic risk
The skill is a normal cloud media-processing helper, but it gives conflicting API domains for authenticated uploads and webhook setup, which could send keys or media to the wrong endpoint.
Review the endpoint before installing or using this skill. Do not upload sensitive local media or configure webhooks unless you confirm the correct RenderIO API host, understand that files and job metadata leave your environment, and are comfortable storing the API key in an environment variable.
The skill is explicitly designed to send media files and processing requests to a third-party cloud service, but it does not prominently warn that user content leaves the local environment. In this context, that omission matters because users may provide sensitive audio, video, or image data without understanding it will be uploaded, stored, and processed externally.
This curl example sends authenticated job submission data to an external host, which is expected for the service, but the documented host inconsistency makes the transmission security-relevant. Users may disclose API keys, source media URLs, and processing instructions to the wrong origin because the example conflicts with the skill's own stated canonical domain.
curl -X POST https://renderio.dev/api/v1/run-ffmpeg-command \
-H "X-API-KEY: $RENDERIO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
The skill declares that the canonical API domain is api.renderio.dev, but key command examples instruct users to send authenticated requests to renderio.dev instead. This inconsistency can cause users or downstream agents to transmit API keys and media payloads to the wrong origin, increasing the risk of credential exposure, failed requests, or interaction with an unintended service endpoint.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
input_files: dict[str, str],
output_files: dict[str, str],
) -> dict[str, Any]:
res = requests.post(
f"{BASE}/api/v1/run-ffmpeg-command",
headers={"X-API-KEY": API_KEY},
json={
This example uploads a local file's contents to an external service along with an API key. External transmission is expected for this skill, but the risk is real here because the example uses a non-canonical domain and lacks an explicit warning that local user files will be exfiltrated to a third-party cloud processor.
const form = new FormData();
form.append("file", new Blob([await fs.readFile(filePath)]), path.basename(filePath));
const res = await fetch("https://renderio.dev/api/v1/files/upload", {
method: "POST",
headers: { "X-API-KEY": API_KEY },
body: form,
The local file upload example posts directly to https://renderio.dev/api/v1/files/upload even though the skill later says the correct domain is api.renderio.dev. Because this flow uploads raw local file contents plus an API key, using the wrong host is more sensitive than a simple documentation typo and can expose user media to an unintended external endpoint.
The webhook section explains how to configure callback delivery but does not warn that job results and metadata will be pushed to an external endpoint controlled by the user or another party. This can lead to unintentional disclosure of output URLs, command IDs, and processing status data, especially if the callback endpoint is misconfigured or publicly accessible.
This webhook configuration request sends an API key and callback settings to an external host. Because the example uses a host inconsistent with the skill's stated canonical domain, it presents a meaningful risk of misdirected authenticated requests and unintended disclosure or misconfiguration of webhook delivery.
# Configure once
curl -X PUT https://renderio.dev/api/v1/webhook-config \
-H "X-API-KEY: $RENDERIO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-server.com/renderio-webhook"}'
The webhook configuration example uses renderio.dev instead of the documented canonical api.renderio.dev, creating the same wrong-origin risk for authenticated configuration changes. Misconfiguring webhooks against an unintended host could leak job metadata or cause users to believe callbacks are secured when they are not configured on the intended API service.
No suspicious patterns detected.