A Miner on Your Git Server Means the Exploit Code Is Public
Commodity payloads and a vendor with no fix put two decisions in front of you: rotate everything your build pipeline trusts, and virtually patch a player you may not know you run.
The payload is the diagnostic
A cryptominer is the least valuable outcome available to an attacker holding code execution on a Git server. That is the point. Miner deployment is the marker of opportunistic, commodity exploitation: the working exploit has left the hands of whoever built it, scanners are running it at volume, and the only remaining variable is whether the instance answers from the internet. The Hacker News reports CISA flagged this activity against a Gitea flaw that was already patched. The interval between advisory and mass exploitation closed inside most organizations' change-control cycle.
A Gitea host is not a web application on the asset register. It holds source code, CI runner registration tokens, deploy keys, personal access tokens, webhook secrets, and a trusted position inside the build pipeline. Any internet-reachable instance should be treated as credential-compromised rather than merely unpatched. Patch the binary, skip the rotation, and the incident moves downstream into artifacts you sign and ship to customers.
mwEmbed is the component your CMDB never listed
CERT/CC disclosed two unauthenticated flaws in Kaltura's mwEmbed HTML5 player: arbitrary file read plus code execution. Both arrived with no vendor patch available. The file read deserves the same weight as the code execution. It is a reliable primitive for harvesting configuration files, API tokens and keys off an otherwise hardened host, without the reliability problems a full exploit chain carries.
Inventory is the harder problem. mwEmbed is embedded infrastructure. It sits inside learning-management platforms, enterprise video portals and marketing microsites, frequently deployed by someone who has since left the organization. Vendors who bundle it are part of the exposure whether or not they have said they ship it, which makes a written patch-ETA request both a mitigation step and a vendor-risk artifact worth holding at renewal.
| Item | Exploit status | Patch | Control that works now | Window |
|---|---|---|---|---|
| Gitea critical RCE | Active exploitation per CISA; miner observed | Yes, released | Patch, then rotate pipeline secrets | Today |
| Kaltura mwEmbed (2 flaws) | Disclosed by CERT/CC; no confirmed exploitation yet | None | WAF virtual patch; decommission unowned instances | 24-48 hours |
Where the reporting is thin, and why it does not change the work
Publicly, neither item carries a CVE identifier or a CVSS score in the available reporting. That is a change-record problem, not an exposure problem: map both through the CISA KEV catalog and vendor advisories when the ticket gets written. The decision to take an internet-facing Git server offline does not depend on having the number in hand.
One pattern worth naming for the SOC queue. A miner on a forgotten development server is the alert class that dies in a backlog, low-value on its face and high-value in what it proves, which is that someone else's exploit already worked on the estate.
The exploitation window on a patched Gitea flaw is now shorter than most organizations' change-control cycle, and the Kaltura player has no fix to schedule at all.
What to do
Patch or take offline every Gitea instance today, discovering hosts by scanning owned IP ranges rather than trusting the CMDB.
Rotate every secret a Gitea host touched within 48 hours — runner registration tokens, deploy keys, PATs, webhook secrets — then hunt those hosts for new cron and systemd units, admin users, SSH keys and webhooks.
Virtual-patch mwEmbed at the WAF this week in log-and-block mode, decommission player instances with no named business owner, and send Kaltura plus every embedding vendor a written patch-ETA and exposure request.