CVE Watch: 13 October 2026, a TRENDnet router bug with a public exploit, and two self-hosted apps shipping secrets

Four new CVE records came up in the batch I read, all published between 10 and 12 October, and none of them sit on the KEV catalog as of its 13 October release ¹. The one I would act on first is a TRENDnet router bug with a public exploit, on hardware the vendor retired in 2011. No firmware update is coming, so the remedy is a replacement ²³.

A public exploit in routers the vendor retired

CVE-2026-108804 covers three TRENDnet models at two firmware builds, the TEW-751DR, TEW-752DRU, and TEW733GR at 1.03B01 and 1.03B03 ². The flaw lives in the web management backend, in pigwidgeon.cgi, where the service argument reaches a fwrite call that builds a shell command. Input that arrives in that argument runs as an operating system command ²³.

VulDB scores the bug 10.0, calls the attack remote and unauthenticated, and points at a downloadable proof of concept ³. The NVD record states the exploit is public and may be used ². A public exploit separates it from the other three records in the batch, none of which carry a report of anyone using them yet.

TRENDnet answered the disclosure with the end-of-life date. The company says it cannot test for a bug in a router it stopped supporting in 2011 and will notify customers of a potential vulnerability ³. The work on my side is inventory: find whether any of those three models still passes traffic anywhere I care about, and if one does, the fix is to power it down, which means deciding what else on that segment depends on it.

A second 10.0 with no vendor reply

CVE-2026-108576 is an OS command injection in the TOZED X300 up to firmware 6.01.3 ⁴. The affected function is process_ping in the IPPingDiagnostics handler, and the field that carries the payload is the host argument ⁴⁵. VulDB scores it 10.0 and describes exploitation as remote, unauthenticated, and easy ⁵. No exploit is available, so the score stands on what the bug allows.

The vendor never answered the disclosure ⁴⁵. VulDB lists no countermeasure and suggests replacing the device ⁵, which is the advice that holds when nobody will write a patch.

The check I run on my own network is reachability. A diagnostic page that takes a hostname from a browser and drops it into a ping command belongs on an internal interface that the internet cannot reach. On a device like this I would confirm that it answers nothing from outside, then reconsider how much I need the device at all.

agnai ships its admin password in the compose file

CVE-2026-108753 affects self-hosted agnai through 1.0.555 ⁶. The project ships a self-host.docker-compose.yml that sets a fixed admin password and a JWT secret, and the application reads those values instead of generating its own ⁶⁷. A fresh database seeds the admin account with the documented password, the login route accepts that password from anyone who can reach it, and a successful login returns an admin token good for 120 days ⁷. The second path needs no password: sign a token with the committed secret, set the admin claim to true, and the API trusts the claim ⁶⁷. With that access, an attacker impersonates users, resets their passwords, and changes the server configuration ⁶.

VulnCheck rates the bug critical and files it under CWE-798, hard-coded credentials ⁸. Nobody has reported exploitation.

The check I run on my Docker hosts takes a minute: read the compose file the project tells you to pull down, and treat every value in it as public. Then set the password and the signing secret yourself before publishing the port. For an instance that is already running, rotation comes first and the login history second, since a token that lasts 120 days leaves a long span to account for.

BotSharp commits its signing key

CVE-2026-108860 covers BotSharp through 5.2.0 ⁹. The WebStarter configuration commits the JWT signing key along with the issuer and audience strings, and VulnCheck files the flaw under CWE-321, hard-coded cryptographic key ¹⁰. The key is an HS256 secret, so anyone who reads the repository can mint a bearer token and reach the Authorize-protected API routes as a known user, administrators included ⁹¹¹. The reporter’s write-up walks through the claims the middleware trusts and the controller actions on the far side of that check ¹¹.

No exploitation is reported for this one. The remedy is a rotation: generate a key, keep it out of the repository, restart the service, and let the old tokens expire. This class of bug gets my attention on the agent frameworks I self-host, because a committed key turns the authentication check into a formality for anyone holding the source ¹¹.

The watch runs each morning from here, and a record earns a section when there is a concrete check I can run on a machine I can reach.