What Happened
CERT/CC disclosed two critical vulnerabilities in Kaltura's HTML5 video player library (mwEmbed) that remain unpatched. The flaws, tracked as CVE-2026-19913 and CVE-2026-19912, both result from unsafe deserialization, allowing remote attackers to read arbitrary files and execute code. CERT/CC was unable to reach Kaltura to coordinate disclosure, leaving organizations using the affected software without a vendor-provided patch.
Timeline
While the exact discovery and disclosure timeline isn't public, the current situation is clear: CERT/CC has published the vulnerabilities, provided mitigation guidance, and confirmed that Kaltura hasn't responded to coordination attempts. This isn't a zero-day scenario where you're racing against active exploitation with no warning. It's worse: you have full knowledge of the vulnerability, clear exploitation paths, and no patch on the horizon.
Which Controls Failed or Were Missing
The technical failures are straightforward. Both vulnerabilities exploit unsafe deserialization in the mwEmbed library. When your application deserializes untrusted data without validation, attackers can craft malicious payloads that the application blindly executes.
But the control failures go beyond code:
Vendor Communication Breakdown: CERT/CC couldn't establish contact with Kaltura, suggesting either non-existent or ineffective security contact channels. If a CERT can't reach you, your customers definitely can't.
Lack of Compensating Controls: Organizations running Kaltura likely didn't have network-level restrictions on the vulnerable endpoints. The mwEmbed library was accessible from external networks without parameter validation or allowlisting.
Missing Dependency Inventory: If you're using Kaltura's video player, do you know which version? Do you have a process to identify all instances across your infrastructure? Many teams discover they're vulnerable only after reading the disclosure.
No Mitigation Playbook: When a vendor goes silent on a critical vulnerability, what's your process? Most organizations don't have one, which means they're improvising under pressure.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that you maintain an inventory of bespoke and custom software and third-party components. If you're processing payment data and using Kaltura, you need to know every instance, every version, and every integration point. This isn't optional.
Requirement 6.3.3 requires you to identify security vulnerabilities using reputable sources and assign a risk ranking to newly discovered vulnerabilities. CERT/CC disclosures count. You can't claim you didn't know.
NIST 800-53 Rev 5 Control SI-2 (Flaw Remediation) requires you to remediate flaws within time frames based on risk assessment. It doesn't say "wait for the vendor." It says remediate. That includes compensating controls when patches aren't available.
ISO/IEC 27001:2022 Control 8.8 (Management of Technical Vulnerabilities) requires you to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate action. "Appropriate action" when the vendor is unresponsive means implementing the mitigations CERT/CC provided.
The standards don't give you an out because Kaltura won't answer the phone. Your obligation is to protect the data, regardless of vendor responsiveness.
Lessons and Action Items
Build a Vendor Communication Escalation Path
Document how you'll escalate when a vendor doesn't respond to security issues. This should include:
- Primary security contact (from vendor's documentation)
- CERT/CC or sector-specific ISAC
- Public disclosure timeline (typically 90 days, but document yours)
- Internal decision point for implementing compensating controls without vendor input
Test this process annually. Send a non-urgent security question to your top 10 vendors and measure response time.
Implement CERT/CC's Mitigations Immediately
For Kaltura specifically, restrict or disable external access to the vulnerable endpoint. If you must leave it accessible, enforce a strict allowlist for the ServiceUrl parameter. This isn't a workaround; it's a control you should have had from the start.
The broader lesson: network segmentation and parameter validation aren't just defense-in-depth. They're your primary defense when vendors fail you.
Create a Third-Party Component Register
You need a real-time inventory that maps:
- Component name and version
- Where it's deployed (all instances)
- What data it touches
- Business criticality
- Last vulnerability scan date
This can't be a spreadsheet someone updates quarterly. Use software composition analysis (SCA) tools integrated into your CI/CD pipeline. When a vulnerability drops, you need answers in minutes, not days.
Define "Unpatched Vulnerability" Procedures
Write down what happens when a critical vulnerability has no patch:
- Who makes the decision to implement compensating controls?
- What's the maximum acceptable time before mitigation?
- Do you disable the functionality, restrict access, or add monitoring?
- How do you track the vendor's status?
For Kaltura users right now, this means: restrict external access today, implement parameter allowlisting this week, and set a calendar reminder to check for patches monthly.
Reconsider Vendor Selection Criteria
If a vendor can't maintain a security contact that CERT/CC can reach, that's a red flag for future procurement. Add "demonstrated vulnerability response process" to your vendor assessment checklist. Ask for evidence: recent CVEs they've addressed, average time to patch, public security advisories.
The uncomfortable truth is that unpatched vulnerabilities in third-party software are your problem, not just the vendor's. The standards hold you accountable for the risk, regardless of who wrote the code. Build your controls accordingly.
