CVE-2026-69113

Executive Summary

CVE-2026-69113 is a broken access control (CWE-862) vulnerability in Cap v0.3.1, a screen-recording / video-hosting product. The flaw affects the POST /api/video/comment endpoint, where any authenticated user can submit a comment to a private video owned by another user merely by supplying an arbitrary videoId in the request body. Successful exploitation allows comment injection into private recordings, triggers notification emails to the victim video owner, and enables enumeration of valid video IDs through response differentials. The vulnerability is currently unpatched (patch confidence 0/4), holds a CVSS base score of 5.4, and has no known public exploit code or CISA KEV listing.

Technical Analysis

The vulnerability is a classic Broken Object Level Authorization (BOLA) / Insecure Direct Object Reference (IDOR) flaw. The affected endpoint, POST /api/video/comment, is implemented in Cap v0.3.1 and expects a request body that includes a videoId parameter identifying the target video and the comment payload. The authorization defect is that the server validates only that the requesting user is authenticated (i.e., session present, PR:L in the CVSS vector), but does not verify that the authenticated user owns the video object referenced by videoId, nor that the video's visibility settings permit third-party commenting.

From a code-architecture perspective, the endpoint likely performs the following sequence, with the critical check missing:

1. Authenticate the caller (token/session validation).
2. Read videoId directly from the request body.
3. Insert the comment record associated with that videoId and the calling user.
4. Trigger a notification (email) to the video owner.

The missing step is an ownership or authorization predicate — e.g., "WHERE video.owner_id = current_user.id" or a call to an access-control function prior to the insert. Because object-level authorization is absent, any authenticated client can reference any videoId, including IDs belonging to private recordings they cannot view.

The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N confirms the profile: remotely exploitable over the network, low attack complexity, requires only low-privileged authentication, no user interaction, scope unchanged, with limited confidentiality impact (C:L) and limited integrity impact (I:L). The confidentiality component stems primarily from the ID enumeration side-effect — the API returns distinguishable responses for valid versus invalid videoId values, allowing an attacker to map the universe of private video identifiers. The integrity component stems from the unauthorized comment injection and the resulting notification emails sent to victims, which can be weaponized for phishing or harassment.

The attack surface is the public-facing Cap API, an HTTP JSON/REST endpoint. Because the flaw is in authorization logic rather than input parsing, input sanitization / SQL hardening provides no protection. The product's OSV package metadata shows an empty affected-version range with state "unfixed," meaning no fixed build has been published.

Exploitation Scenarios

No public PoC, Nuclei template, or exploit code is currently available; the attack chain below is inferred strictly from the vulnerability class and the NVD description.

Step 1 — Reconnaissance / target identification. An attacker with any valid low-privileged account on a Cap instance authenticates to the API and observes legitimate usage of the comment feature (e.g., posting a comment on their own video to learn the request shape). Valid videoId values are then enumerated using the response-difference oracle described in the NVD entry: issuing requests with random or sequential/guessable IDs and distinguishing "video not found" responses from "comment accepted" responses. Modern recorded-video IDs are often UUIDs, but if the implementation uses sequential integers or time-based identifiers, enumerating the full ID space is trivial. Even with non-guessable IDs, the endpoint can be used as an existence oracle.

Step 2 — Triggering the flaw. The attacker crafts a POST request to /api/video/comment with a JSON (or form-encoded) body containing an arbitrary videoId harvested in Step 1 plus comment text. Because the endpoint lacks object-level authorization, the request is accepted for any videoId regardless of the caller's relationship to the underlying video object. No special privileges, admin roles, or relationship conditions are required beyond a valid authenticated session.

Step 3 — Payload / execution method. The payload is not an injection payload in the SQLi/XSS sense — it is simply a well-formed API request with a victim-owned videoId. The vulnerability class is missing authorization checks, so the "payload" is the object reference itself. The attacker can script this loop over many discovered IDs to mass-comment across the platform, include malicious URLs in comment text to convert the notification email into a phishing delivery channel, or bury defamatory content in specific victims' private recordings.

Step 4 — Post-exploitation impact. Impact recursively compounds: (a) the attacker achieves confidentiality violation by confirming which videoId values exist, including those of private videos; (b) the attacker achieves integrity violation by planting comments inside private video records that the video owner will read; (c) the notification email triggered by each comment creates a spam/phishing vector — an attacker-controlled message delivered by the Cap platform's own infrastructure to the victim's inbox, lending the content false legitimacy; and (d) mass enumeration can feed further targeted attacks, distinguishing active users, mapping platform usage, and enabling account-takeover or harassment campaigns.

Impact Assessment

• Business impact: For any organization self-hosting or relying on Cap v0.3.1, the primary business risks are (1) breach of privacy expectations for internal/private recordings — a legal and compliance concern where recordings contain sensitive business discussions, HR matters, or customer data; (2) reputational damage if attackers plant abusive or malicious content inside private videos; and (3) abuse of trusted notification emails to phish employees, potentially leading to credential theft or internal compromise.
• Affected systems: All Cap v0.3.1 deployments exposing the /api/video/comment endpoint to authenticated users. Since the affected-version metadata lists no fixed versions, the entire known release line is presumed vulnerable.
• Blast radius: The confidentiality impact is bounded (L) because the attacker does not directly read video content — only ID existence and the ability to write comments. The integrity impact is likewise bounded (L) because only comment data is modified. However, the notification email phishing vector widens the practical blast radius by turning every video owner into a potential phishing target, and ID enumeration defeats the platform's security-by-obscurity for private-content discovery.
• CVSS subscores: The 5.4 base score reflects the low complexity (AC:L), low privilege requirement (PR:L), and the absence of user interaction (UI:N). It is a medium-severity issue best understood as a systemic authorization gap rather than a single fire-and-forget exploit.

Detection Guidance

Sigma Rule

title: CVE-2026-69113 - Cap Broken Access Control on Video Comment API
id: 8f3d2c6e-9a2b-4f5e-8b7d-1c2d3e4f5a6b
status: experimental
description: >
  Detects POST requests to /api/video/comment with a videoId parameter,
  which may indicate attempted BOLA/IDOR abuse of Cap v0.3.1 by an
  authenticated user targeting private videos.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-69113
author: Valters IT Security Research
date: 2026/05/15
logsource:
  category: webserver
  definition: Reverse proxy or application server access logs in front of the Cap API service.
detection:
  selection:
    http.method: POST
    http.url.path: "/api/video/comment"
  filter_no_body:
    http.request.body.text: null
  condition: selection and not filter_no_body
fields:
  - src_ip
  - user.name
  - http.url.query
  - http.request.body.text
falsepositives:
  - Legitimate comment POSTs by video owners on their own recordings
  - Automated test suites exercising the comment endpoint
level: medium
tags:
  - attack.t1190
  - cve.2026-69113
  - cwe.862

YARA Rule

rule CVE_2026_69113_Cap_BOLA_Comment_API
{
    meta:
        author = "Valters IT Security Research"
        description = "Matches HTTP request captures or logs referencing the Cap /api/video/comment endpoint and videoId parameter."
        cve = "CVE-2026-69113"
        cwe = "CWE-862"
        date = "2026-05-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-69113"
    strings:
        $a = "/api/video/comment" ascii wide nocase
        $b = "videoId" ascii wide nocase
        $c = "comment" ascii wide nocase
        $d = "POST" ascii wide nocase
    condition:
        any of them and all of ($a, $b)
}

Note: The rule is intentionally generic because the exploit payload is a well-formed API request with no malicious byte patterns. It is most useful for hunting in pcap captures or proxy logs exported to text/HTTP format.

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2026-69113 - Cap POST /api/video/comment possible BOLA/IDOR attempt";
    flow:established,to_server;
    http.method;
    content:"POST";
    http.uri;
    content:"/api/video/comment";
    http.request_body;
    content:"videoId";
    http.request_body;
    pcre:"/videoId[\"']?\s*[:=]/i";
    classtype:attempted-user;
    sid:69113001;
    rev:1;
    metadata:created_at 2026_05_15, cve CVE-2026-69113, cwe CWE-862;
)

Elastic Detection

EQL query for Elasticsearch (auditbeat / elastic-endpoint HTTP events):

sequence by source.ip with maxspan=1m
  [ network where network.protocol == "http"
      and http.request.method == "POST"
      and url.path == "/api/video/comment"
      and length(http.request.body.text) > 0 ]
  [ network where network.protocol == "http"
      and http.response.status_code == 200
      and url.path == "/api/video/comment" ]

This two-event sequence correlates a successful POST to the vulnerable endpoint. SIEM operators should enrich hits with the authenticated username and compare the referenced videoId against the user's own video records; a mismatch is a strong indicator of BOLA exploitation. A threshold variant (e.g., 10+ distinct videoId values from one user within 5 minutes) detects enumeration behavior.

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=nginx:plus
method=POST uri_path="/api/video/comment"
| rex field=form_data "videoId[=:](?<videoId>[^&\"}]+)"
| stats values(videoId) AS referenced_videos, dc(videoId) AS distinct_videos,
        count AS request_count, min(_time) AS first_seen, max(_time) AS last_seen
        BY src_ip, user, uri_path
| where distinct_videos > 5
| sort - request_count
| table _time, src_ip, user, distinct_videos, referenced_videos, request_count

This search first filters for the vulnerable endpoint, extracts the videoId value from the request body, then aggregates per source IP and user. High distinct-video counts indicate enumeration or mass-comment abuse. Extend with a lookup joining videoId to video owner_id to confirm victims are not the poster.

Wazuh OSSEC Rule

<group name="web,accesslog,cve-2026-69113,">
  <rule id="691131" level="12" frequency="12" timeframe="300">
    <if_matched_sid>100002</if_matched_sid>
    <match>POST /api/video/comment</match>
    <description>CVE-2026-69113: Repeated POSTs to Cap /api/video/comment detected - possible Broken Object Level Authorization abuse</description>
    <group>web_application_attack,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

This rule should be deployed alongside the standard Apache/Nginx access-log decoder and will fire when 12 or more requests to the vulnerable endpoint occur within 300 seconds, flagging enumeration or mass-comment activity.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source, the vendor fix field is N/A, no workarounds are officially documented, and the OSV package state is "unfixed." Treat any Cap instance running v0.3.1 as fully exposed to this vulnerability.

1) Immediate mitigations (no code fix required):

• Place a reverse proxy or WAF rule in front of /api/video/comment that strips or rejects request bodies containing a videoId that differs from IDs owned by the authenticated session — where the platform supports such correlation at the proxy layer.
• If the comment feature is not business-critical, disable or block the POST /api/video/comment endpoint outright until a patched release ships.
• Monitor and rate-limit per-user comment POSTs aggressively; short-term alerting per the Detection Guidance section above can catch enumeration before it completes.
• Review platform settings to disable comment notification emails globally, eliminating the phishing/spam delivery vector while the flaw is open.

2) Patch / upgrade steps:

• No fixed version exists. Track the vendor's release channel (product site: https://cap.so) for a patched build, and subscribe to the NVD CVE entry for status changes.
• Before upgrading, test the fix in a staging environment by verifying that posting a comment to a videoId owned by a second account returns 403/404 and triggers no notification email.
• If self-hosting, diff the vendor's source for the next release and confirm that an object-ownership authorization check was inserted in the comment handler.

3) Long-term hardening:

• Adopt OWASP API Security Top 10 — API1:2023 (Broken Object Level Authorization) controls: enforce server-side ownership checks on every object reference in each API handler, never trust client-supplied object IDs.
• For future endpoints, require canonical object references (IDs resolved server-side from the session context) rather than arbitrary client-supplied IDs.
• Implement centralized authorization middleware so that per-route authorization is enforced by default and bypassing it requires explicit, reviewed exceptions.
• Add positive security tests: for each API route that touches resources, assert that user A cannot read/write user B's objects.
• Rotate or re-map any short/sequential video ID schemes toward unguessable identifiers, while understanding that this only slows ID enumeration — it does not fix the authorization flaw itself.

References

1. NVD entry for CVE-2026-69113 — https://nvd.nist.gov/vuln/detail/CVE-2026-69113
2. MITRE CWE-862 (Missing Authorization) — https://cwe.mitre.org/data/definitions/862.html
3. OWASP API Security Top 10, API1:2023 — Broken Object Level Authorization — https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
4. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-69113 not currently listed; monitor for changes) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
5. Vendor product site for Cap (watch for security advisories / release notes) — https://cap.so

Threat-actor campaign evidence: None reported. There is no evidence of exploitation in the wild, no CISA KEV inclusion, no public exploit code, and no Nuclei template as of analysis date. The EPSS score of 0.00223 (13.2nd percentile) indicates a low current probability of exploit-in-the-wild; however, the unpatched status and trivial, authenticated exploitation profile make this a candidate for inclusion in future exploit kits once disclosed more broadly.