--- title: "Security Incident Report: Compromise of Self-Hosted Gitea and Plausible" description: "A plain-language report on the compromise of our self-hosted Gitea and Plausible servers in autumn 2026: what happened, what we found, and what we changed." image: https://mktg.nhcarrigan.com/hubfs/Generated_Image_September_29_2026_-_9_34PM.jpg --- [Skip to content](https://mktg.nhcarrigan.com/blog/security-incident-october-2026#main-content) [![](https://mktg.nhcarrigan.com/hs-fs/hubfs/logo.png?width=2048&height=2048&name=logo.png)Homepage](https://nhcarrigan.com) - [Code](https://git.nhcarrigan.com) - [Socials](https://socials.nhcarrigan.com) - [Documentation](https://docs.nhcarrigan.com) [Join Discord](https://chat.nhcarrigan.com) - [Code](https://git.nhcarrigan.com) - [Socials](https://socials.nhcarrigan.com) - [Documentation](https://docs.nhcarrigan.com) [Join Discord](https://chat.nhcarrigan.com) ![](https://mktg.nhcarrigan.com/hs-fs/hubfs/Generated_Image_September_29_2026_-_9_34PM.jpg?width=6336&height=2688&name=Generated_Image_September_29_2026_-_9_34PM.jpg) # Security Incident Report: September to October 2026 ![Naomi Carrigan](https://mktg.nhcarrigan.com/hs-fs/hubfs/Generated_Image_1790742324098.jpg?width=48&height=48&name=Generated_Image_1790742324098.jpg) Naomi Carrigan October 7, 2026 *Incident reference: 2026-10-breach. Status: contained and closed. All times are Pacific Time (UTC-7) unless stated.* ## Summary On 6 October 2026 we confirmed that two self-hosted services on our production server had been compromised through publicly disclosed vulnerabilities that we had not yet patched: **Gitea**, which hosted our source code, and **Plausible Community Edition**, which provided website analytics. Attackers used both to run cryptocurrency miners (XMRig, mining Monero) on our server. We found no evidence that the server itself was taken over, no implants still running, and no evidence that data was copied off the server. Both services have been permanently decommissioned, our code now lives on GitHub, and we have hardened the server. - **Detected:** 6 October 2026. - **Earliest malicious activity:** 30 August 2026 (Gitea, an exploit-confirmation scan), 16 September 2026 (Plausible). - **Impact:** unauthorised code execution inside two containers, resource theft (mining), and exposure of the secrets those services held. - **Not found:** evidence of root-level access, credential-stealing code, staged data or misuse of our mail account. ## What was affected | Service | What happened | Status | | --- | --- | --- | | Gitea (code hosting) | Exploited through CVE-2026-59774 (GHSA-6v53-hr58-556r), an unauthenticated file-read flaw that leads to remote code execution. A scanner confirmed the weakness on 30 August. A cryptominer operator took over on 28 and 29 September, and a miner ran from 30 September until we stopped the service on 6 October. | Compromised. Decommissioned. | | Plausible CE v3.1.0 (analytics) | Exploited through CVE-2026-8467 (GHSA-mhcv-h7gf-57cf), an unauthenticated remote code execution flaw in the `/storybook` endpoint, fixed in version 3.2.1. Miners ran from at least 16 September. | Compromised. Decommissioned. | | The production server | No evidence of root-level compromise. | Hardened. Further updates in progress. | | Our other self-hosted services | No evidence of compromise. Several (including our forum, task tracker, file host and translation service) were retired as a precaution. | Retired or being reviewed. | ## Timeline | When | What | | --- | --- | | 3 June | Plausible publishes a critical advisory (fixed in 3.2.1). We were running 3.1.0. | | 2 August | Gitea publishes the file-read advisory (fixed in 1.27.1). | | 30 August | A scanner injects a hook into one repository on our Gitea. It writes a marker file and makes a DNS callback to confirm the server is exploitable. | | 16 September | Earliest evidence of attacker code running in our Plausible container. | | 22 September to 6 October | About 580 probe requests to the vulnerable Plausible endpoint, all answered until the service was stopped. | | 28 September, 19:30 | First request in our retained logs from the Gitea attacker. The first full exploit round follows at 21:11. | | 29 September, 03:31 | The attacker installs a malicious setting in Gitea's global git configuration. | | 30 September | A miner starts (09:33). From 1 October a supervisor process keeps it running. | | 6 October, 11:43 | We stop Gitea after an update leaves it failing to start. | | 6 October, 12:04 to 13:43 | We restart Gitea while troubleshooting. Git fetches begin timing out after exactly 60 seconds. | | 6 October, about 13:40 | We identify the malicious hook as the cause of the timeouts. | | 6 October, 13:43 | Containment: Gitea is stopped again and outbound traffic to the known attacker addresses is blocked. | | 6 October, 13:45 to 15:05 | We capture evidence from the Plausible container, then remove it. | | 6 October, evening | Binary analysis in an isolated sandbox, a host-wide sweep for leftovers, cleanup, and a final verification at about 20:00. | ## How the attacks worked ### Gitea The flaw let an anonymous visitor read arbitrary files from the server through the repository markup renderer. The attacker used it to read Gitea's configuration, including an internal API token. That token let them call an internal logging endpoint, which they abused to plant a global git setting (`uploadpack.packObjectsHook`) pointing at a shell script. From then on, every `git fetch` or clone against the server ran their script. The script downloaded a second-stage installer and a bot, which started and supervised XMRig miners. The miners connected to public Monero pools over TLS. The bot could also have installed persistence on the host, but we found no sign that it did. ### Plausible The vulnerable endpoint allowed anonymous remote code execution inside the Plausible container. The attacker started two miners as children of the application process. ## How we found it After updating Gitea on 6 October, `git pull` against it kept failing: the first request succeeded and the next one hung for exactly 60 seconds, which is our proxy timeout. A process listing during one of those hangs showed the fetch running through a script that did not belong there, and reading that script showed it was a dropper. ## What we know about data exposure - **Proven:** the attacker held Gitea's internal token and could run commands inside the Gitea container as its service account, with access to everything in its data directory (database, configuration, repositories). - **The file read itself:** about 6.5 KB was returned in total, so it was not used to copy data in bulk. The files read were most likely the configuration file. - **Binary and script analysis:** we analysed all four binaries and the installer in an isolated sandbox. The miners are stock XMRig. We found no credential-harvesting, archiving or upload logic in any of them, and none in the installer (moderate confidence). - **No staged data:** no archives or dumps were found in the containers or on the host, and no unexplained outbound connections appeared in the snapshots we took. - **Mail:** the account that Gitea used to send email logged in from our own server only, with no sign of misuse. - **Limits:** we have no network flow logs, our web logs only reached back to 22 September, and the period from 30 August to 6 September is not covered by retained mail logs. Absence of evidence is therefore weaker than we would like. **What this means for you:** if you had an account on our Gitea (git.nhcarrigan.com), assume its username, email address, password hash, two-factor secret and any access tokens were exposed. If you reused that password anywhere else, change it. The service no longer exists. ## What we did - Stopped the affected services, blocked the attacker addresses (now a persistent firewall rule) and preserved the evidence. - Analysed the binaries and scripts in an isolated sandbox, then verified the evidence bundle and moved it to cold storage. - Swept the host for leftovers: no attacker files outside the evidence folders, no live connections to any attacker address, no unexpected persistence. - Decommissioned Gitea and Plausible and removed their data directories, along with the root-level runners that depended on Gitea. - Moved our repositories to GitHub as clean mirrors (server-side hooks and configuration were not copied), and scrubbed the secrets that scanning found in the history of the repositories that had them. - Removed an over-broad passwordless sudo rule, restored correct ownership on our web server configuration, and restarted a monitoring service that had been leaking memory. ## Root cause and contributing factors - **Unpatched, internet-facing software.** Both flaws were publicly documented weeks or months before they were used against us, and our update process did not catch them. - **Services published directly through Docker.** Docker's port publishing bypassed the host firewall, so several services were reachable without going through our web server. - **Too much shared privilege.** The services ran under the same user ID as our other applications. - **Thin logging.** Fourteen days of web logs and no outbound network logging limited what we could prove. ## What we are doing next - Applying the pending operating-system updates and rebooting the server onto the current kernel. - Keeping logs longer and shipping them off the server, including outbound connection logs. ## Indicators of compromise We are sharing these so that others running similar software can check themselves. None of the addresses were contacted during our investigation. **Addresses (outbound traffic to all six is now blocked):** the first four are attacker infrastructure (download hosts and command servers). The last two are miner endpoints that our Plausible container was connected to. ``` 38.127.244.12 162.4.173.102 80.87.206.86 85.137.54.178 103.189.234.47 45.77.67.39 ``` **Git configuration:** any `uploadpack.packObjectsHook` entry in a global git config that points at a script, in particular `sh /data/gitea/home/.pwn`. **Files and names:** `.pwn`, `.ext4402`, `.boat_landed`, `ksoftirqd` (outside the kernel thread list), `linuxsys`, `syslog-ng-ee175527`, `/var/tmp/.syslog-*`, `.upd_boat`, the abstract socket `boat_mutex_v4`, and the bot string `boatnet-unit-v2`. Marker file `/tmp/CVE-2026-59774.proof` and DNS callbacks to `oob.smartdnslog[.]com` belong to the earlier scanner. **Request patterns:** `POST /{owner}/{repo}/markup` with an Org-mode include directive, calls to `/api/internal/manager/add-logger`, and `GET /storybook/iframe/button` requests carrying `topic=pwn`. **SHA-256:** | File | SHA-256 | | --- | --- | | linuxsys (XMRig) | `4d17d32ed6efe92ea61d16602f9c6cd5261cdd3820adec427ee68d4088b6ab5b` | | syslog-ng-ee175527 (XMRig) | `b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49` | | Stage-2 installer (`/i`) | `fb3c23572dfd971ac52dd7991373631978b2107c8f2fa4348f87924d7d834dd8` | | ksoftirqd (XMRig), prefix only | `315217b58357...` | | .ext4402 (bot), prefix only | `676149d53fe8...` | ## How confident are we? We are confident about the Gitea findings and timeline, and confident that the server itself was not breached and that nothing was exfiltrated. The main gaps are the command channel the bot used (we saw the addresses but never the traffic), earlier versions of the attacker's script that were overwritten, and the unlogged period from 30 August to 6 September. If we learn anything that changes these conclusions, we will update this post. ## References - [Gitea advisory GHSA-6v53-hr58-556r (CVE-2026-59774)](https://github.com/go-gitea/gitea/security/advisories/GHSA-6v53-hr58-556r) - [Plausible advisory GHSA-mhcv-h7gf-57cf (CVE-2026-8467)](https://github.com/plausible/analytics/security/advisories/GHSA-mhcv-h7gf-57cf) - [Our security policy](https://docs.nhcarrigan.com/legal/security/) ## Share this post [mailto:https%3A%2F%2Fmktg.nhcarrigan.com%2Fblog%2Fsecurity-incident-october-2026](mailto:https%3A%2F%2Fmktg.nhcarrigan.com%2Fblog%2Fsecurity-incident-october-2026) ## Keep reading ### [![](https://mktg.nhcarrigan.com/hs-fs/hubfs/Generated_Image_September_29_2026_-_9_34PM.jpg?width=6336&height=2688&name=Generated_Image_September_29_2026_-_9_34PM.jpg) I Stayed for 36 Hours Straight. Here Is Why](https://mktg.nhcarrigan.com/blog/ai-hackathon-berkeley-2026) ### [![](https://mktg.nhcarrigan.com/hs-fs/hubfs/Generated_Image_September_29_2026_-_9_34PM.jpg?width=6336&height=2688&name=Generated_Image_September_29_2026_-_9_34PM.jpg) ADHD and Software Engineering](https://mktg.nhcarrigan.com/blog/adhd-and-software-engineering) --- [Privacy Policy](https://docs.nhcarrigan.com/legal/privacy/) · [Terms of Service](https://docs.nhcarrigan.com/legal/terms/) · © NHCarrigan 2026. All rights reserved.   15640 NE Fourth Plain Blvd, Ste 106 #923 Vancouver, Washington 98682 United States (971) 303-8662‬   ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Naomi Carrigan", "url" : "https://mktg.nhcarrigan.com/blog/author/naomi" }, "dateModified" : "2026-10-07T03:12:42.290Z", "datePublished" : "2026-10-07T03:12:42.000Z", "headline" : "Security Incident Report: Compromise of Self-Hosted Gitea and Plausible", "image" : [ "https://mktg.nhcarrigan.com/hubfs/Generated_Image_September_29_2026_-_9_34PM.jpg" ], "mainEntityOfPage" : { "@id" : "https://mktg.nhcarrigan.com/blog/security-incident-october-2026", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://mktg.nhcarrigan.com/hubfs/logo.png" } } } ```