The CERT Coordination Center (CERT/CC) has disclosed two unpatched vulnerabilities in Kaltura's HTML5 video player library that allow a remote, unauthenticated attacker to read arbitrary files from a server and execute code on it.
The flaws, tracked as CVE-2026-19913 and CVE-2026-19912, both stem from the same unsafe deserialization in the mwEmbedLoader.php endpoint of the mwEmbed player library, which Kaltura also distributes as html5lib.
Neither requires authentication or a Kaltura session token, and network access to the endpoint is the only precondition CERT/CC states.
No patch is available, and CERT/CC said it was "unable to reach Kaltura to coordinate these vulnerabilities." Administrators are advised to restrict or disable external access to the endpoint and to enforce a strict allow-list for the ServiceUrl parameter that permits only legitimate backend API URLs.
No exploitation had been reported at the time of writing, and neither CVE appeared in CISA's Known Exploited Vulnerabilities (KEV) catalog as of August 25, 2026.
CERT/CC describes Kaltura as a video platform providing tools for video management, publishing, playback, and integration with web applications. The vulnerable loader is exposed on customer installations and on Kaltura's own shared production hosts.
"Because the affected endpoint is also exposed on Kaltura's shared, multi-tenant CDN infrastructure, these vulnerabilities affect not only individual customer installations, but also every tenant served by these shared hosts," CERT/CC said in the vulnerability note.
The file read issue, CVE-2026-19913, starts with the ServiceUrl parameter, which mwEmbedLoader.php accepts and uses as the target URL for backend API requests. The KalturaClientBase PHP client fetches whatever that URL returns and passes it to PHP's unserialize() without validating the source, the scheme, or the content.
Supplying a file:// path causes the server to fetch a local file rather than an API response. The deserialization attempt then fails. The raw bytes of the fetched file are reflected back to the requester inside the resulting error message.
Gerjan Wemekamp, the AndDone researcher credited with reporting both flaws, said in a technical writeup published Tuesday that he escalated the file read by retrieving the Kaltura application configuration at /opt/kaltura/app/configurations/local.ini, which holds plaintext database connection strings, admin and console passwords, and internal host references.
The second flaw, CVE-2026-19912, turns the same deserialization into code execution by way of the uiconf_id request parameter, which is appended to the cache folder path without sanitization when the application writes to disk.
An attacker points ServiceUrl at a malicious serialized object carrying executable PHP code. The client fetches and deserializes it. A uiconf_id value containing traversal sequences such as ../ then redirects the write outside the intended cache directory and into a web-accessible one. Requesting that file directly executes it as the web-server user.
"The file-drop step depends on the file-based cache backend, which is the Kaltura default. A memcache-only configuration may suppress the write and therefore that specific RCE path. However, that does not make the deployment safe," Wemekamp said.
With no fixed version to install, administrators running the player are advised to perform the following steps -
- Block or remove the endpoint at the WAF, reverse proxy, or CDN where legacy mwEmbed players are not being served.
- Allow-list
ServiceUrl, permitting only the deployment's own API host and rejecting non-HTTP(S) schemes. - Reject
uiconf_idvalues containing traversal sequences, absolute paths, or directory separators. - Deny PHP execution in cache directories.
- Restrict outbound network access from the application server, which the code execution path needs in order to fetch the payload.
- Rotate everything in
local.iniwhere the endpoint has been exposed, covering database credentials, admin and console passwords, partner secrets, and API keys.
CERT/CC lists the affected releases as html5lib v2.45, v2.103 and earlier, and other v2.x releases that expose the vulnerable endpoint.
Wemekamp scored CVE-2026-19912 at 10.0 and CVE-2026-19913 at 9.1, labeling both in his writeup as reporter-assigned. CERT/CC published no score for either flaw, and there was no NVD record for either identifier as of August 25, 2026.
NIST said in April that it no longer enriches every CVE, prioritizing those in the KEV catalog, software used within the federal government, and software designated critical under Executive Order 14028.
The researcher was explicit about what he did and did not demonstrate.
"To be exact about scope: the end-to-end web shell drop was demonstrated on the Kaltura Server docker image from 2019. What I verified on the current release is that both halves of the chain are present, and that the deserialization half still executes as described," Wemekamp said.
The Hacker News verified against Kaltura's public server repository on August 25 that deployment/uiconf/KalturaClientBase.php, the file carrying the unserialize() call, is byte-identical across 21 release refs, from Jupiter-10.9.0, committed on April 27, 2015, to West-23.5.0, committed on August 13, 2026. The call and the error-message reflection appear earlier still, in a release ref committed on March 10, 2014.
Kaltura has stripped unsafe deserialization out of its codebase before. In August 2017, weeks ahead of a Telekom Security advisory covering three flaws in the platform, the company shipped a commit that removed three unsafe unserialize calls, and the vendor fixed those issues in release 13.2.0. That commit touched three files, none of which was KalturaClientBase.php.
Unsafe deserialization without an available fix has recurred elsewhere this year. In July, Fastjson 1.x was targeted in attacks with another unpatched deserialization flaw, with no patched 1.x artifact published at the time.
Kaltura's published security.txt, last updated May 28, 2024, directs vulnerability reports to a bug bounty program on HackerOne and lists security@kaltura.com for security inquiries.
The researcher's timeline records a first report to a vendor security contact on March 23, 2026. He re-sent it from a corporate address on April 13. He contacted the vendor's CISO on LinkedIn on May 23. He escalated the case through a national CERT on July 2.
CERT/CC notified Kaltura on July 8, and the note lists the vendor's status for both CVEs as Unknown, with no statement received. Neither source states which address or channel the initial reports were sent to.
