CERT/CC has disclosed two unpatched security vulnerabilities affecting Kaltura’s HTML5 video player library, specifically the mwEmbed loader endpoint. In short: the flaws can allow a remote, unauthenticated attacker to read arbitrary files from a server and, in a related scenario, execute code on it.
The issues are tracked as CVE-2026-19913 (file read) and CVE-2026-19912 (code execution). Both originate from the same unsafe deserialization behavior in mwEmbedLoader.php, which Kaltura also distributes as html5lib.
Why the Unpatched Kaltura mwEmbed endpoint is dangerous
According to CERT/CC, neither vulnerability requires a Kaltura login nor a session token. The only prerequisite is network access to the vulnerable endpoint. That matters because the loader can be reachable on both customer deployments and Kaltura’s shared production hosts.
CERT/CC also notes a multi-tenant impact risk: since the endpoint is exposed via Kaltura’s shared, multi-tenant CDN infrastructure, more than a single customer installation can be affected through the shared hosting model.
Root cause: unsafe deserialization in mwEmbedLoader.php
Both CVEs stem from unsafe deserialization in the mwEmbedLoader.php endpoint. CERT/CC attributes the problematic behavior to how the server fetches data from a URL provided by the attacker, then passes it into PHP’s unserialize() without validating what it is, where it came from, or which scheme it used.
In other words, the endpoint takes attacker-influenced inputs, fetches content based on them, and then attempts to deserialize the result as if it were trusted data. That combination is what enables both the file read and the code execution chains.
Vulnerability 1 (CVE-2026-19913): remote file read
The file read issue begins with the ServiceUrl parameter. CERT/CC explains that mwEmbedLoader.php accepts ServiceUrl and treats it as the target for backend API requests. The fetched bytes are then processed via the Kaltura PHP client.
The key problem: the server does not properly validate the source of ServiceUrl. For example, CERT/CC describes that supplying a file:// path can cause the server to fetch a local file instead of receiving an API response. When deserialization fails, the raw bytes of the fetched file can be reflected back to the requester inside the resulting error message.
This turns a deserialization error into a data exposure vector, because the attacker effectively gets portions of server-resident files echoed back to them through the error handling.
What the researcher demonstrated with local.ini
In a technical write-up credited to researcher Gerjan Wemekamp, the reporter is said to have verified the impact by obtaining Kaltura configuration content from a path such as:
- /opt/kaltura/app/configurations/local.ini
CERT/CC states that this configuration file can contain plaintext database connection strings, admin and console passwords, and references to internal hosts. That means a file read primitive may quickly lead to broader compromise if credentials and internal endpoints are exposed.
Vulnerability 2 (CVE-2026-19912): code execution via file drop
The second flaw reuses the same unsafe deserialization weakness, but it is extended into a code execution scenario through a disk write step. CERT/CC describes that the attacker can manipulate the request using the uiconf_id parameter.
In the vulnerable behavior, uiconf_id is appended to a cache folder path without sanitization when the application writes to disk. That omission enables directory traversal techniques (for example, using sequences such as ../) to redirect where the server writes.
An attacker can then provide a malicious serialized payload (pointed to through ServiceUrl) so that the deserialization results in a write of attacker-chosen content. If the traversal sends the dropped file into a location that is web-accessible, requesting that file can lead to execution as the web-server user.
Does configuration change eliminate the risk?
Wemekamp notes that the file-drop stage depends on a file-based cache backend, which is Kaltura’s default. If the deployment uses a memcache-only configuration, the write step might be suppressed—potentially preventing the specific RCE path.
However, CERT/CC emphasizes that this does not automatically make the deployment safe. Even if one chain is hindered, the underlying unsafe deserialization behavior and the file read exposure remain concerns, and the environment may still be vulnerable under other conditions.
No patch available: CERT/CC coordination status
At the time of disclosure, CERT/CC reports that there was no available patch. The organization also said it was unable to reach Kaltura to coordinate the vulnerabilities. Administrators are therefore expected to rely on mitigation and exposure reduction.
Additionally, CERT/CC notes that the two CVEs were not present in CISA’s Known Exploited Vulnerabilities (KEV) catalog as of August 25, 2026. (That can change over time, so defenders should not treat “not in KEV” as “no risk.”)
Concrete mitigation steps for Unpatched Kaltura mwEmbed
CERT/CC advises administrators to reduce exposure and harden inputs. The guidance below focuses on blocking the vulnerable surface and limiting what the loader is allowed to access or write.
1) Block or remove the vulnerable endpoint
If legacy mwEmbed players are not needed, consider removing or blocking mwEmbedLoader.php at your perimeter—such as via a WAF, reverse proxy, or CDN.
2) Allow-list ServiceUrl strictly
CERT/CC recommends enforcing a strict allow-list for the ServiceUrl parameter. The allow-list should permit only the deployment’s own backend API URLs and reject non-HTTP(S) schemes (for example, blocking file:// or other unexpected schemes).
3) Validate uiconf_id against traversal and path injection
For the code execution path, reject uiconf_id values that contain traversal sequences, absolute paths, or directory separators. Treat this parameter as hostile even if it seems internal.
4) Deny PHP execution in cache directories
To reduce the impact of any file drop, harden the environment so that PHP cannot execute from cache directories. This limits the attacker’s ability to turn written files into runnable code.
5) Restrict outbound network access from the application server
Because the code execution chain depends on the application reaching attacker-controlled content (via the fetch behavior), you should restrict outbound network access from the server hosting the endpoint.
6) Rotate exposed secrets in local.ini
CERT/CC advises rotating everything in local.ini wherever the vulnerable endpoint was exposed. This includes:
- database credentials
- admin and console passwords
- partner secrets
- API keys
Rotation is particularly important because the file read flaw can expose these values directly or indirectly.
Which versions are affected?
CERT/CC lists affected releases including html5lib v2.45, v2.103 and earlier, and other v2.x releases that expose the vulnerable endpoint. The specific exposed endpoint behavior is what matters for practical risk assessment, but version information helps triage.
Why the issue still matters even if you think you’re safe
Security teams sometimes assume that “video player library” vulnerabilities are limited. In this case, however, the weaknesses involve fundamental server-side behaviors: fetching attacker-chosen URLs and then deserializing them unsafely. That can translate quickly from a media feature to a system compromise.
Furthermore, CERT/CC highlights that Kaltura’s shared, multi-tenant infrastructure can broaden the impact beyond one installation. So defenders should not only check their own servers, but also review how their hosting model exposes the endpoint.
Looking at prior changes and ongoing deserialization risk
It is also worth noting that Kaltura has previously removed unsafe deserialization code in older fixes. CERT/CC references a commit shipped in August 2017 that removed unsafe unserialize calls, with those issues later fixed in a release 13.2.0.
Still, the reappearance of unsafe deserialization weaknesses this year across different technologies reinforces a broader lesson: when fixes remove one instance but similar patterns remain elsewhere, the system can remain vulnerable. That’s why exposure reduction and input validation are critical when no patch is available.
Bottom line
The Unpatched Kaltura mwEmbed vulnerabilities disclosed by CERT/CC (CVE-2026-19913 and CVE-2026-19912) combine unauthenticated remote exposure with unsafe deserialization. The result can be file disclosure and, under the right conditions, remote code execution.
Because no fixed version is available in the disclosure, the safest immediate approach is to block the endpoint, allow-list ServiceUrl, harden uiconf_id, prevent PHP execution in cache paths, limit outbound connections, and rotate credentials that may have been exposed.
Source: https://thehackernews.com/2026/08/unpatched-kaltura-mwembed-flaws-could.html
