An attacker can get what they came for while your application carries on working.
Pages load, background jobs finish, customers carry on with their day. Meanwhile, a credential copied from that machine is being used somewhere else, against a different service, on your account.
That possibility is why I’ve become interested in canaries. There’s a gap between knowing your software is working and knowing somebody has been rummaging through it.
The PHP disclosure on 21 October makes that gap uncomfortable. Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated remote code execution. For Apache’s mod_php, the PHP team described a demonstrated exploit that can trigger before any application code runs.
Before your application gets a chance to do anything.
You can spend considerable effort reasoning about your routes, authentication and permissions, while a vulnerability underneath that code creates another way in. An advisory tells you that possibility exists. Establishing what happened inside your own environment is a separate problem.
And the thing someone came looking for might fit on a single line.
An OpenAI API key. Cloud credentials. A database connection string. Something that gives them access to a service you’re already paying for.
This behaviour predates the latest PHP bugs. In May 2024, Sysdig documented an attack that obtained cloud credentials through a vulnerable Laravel application and attempted to access hosted language models. The associated tooling could check credentials across ten AI services, including OpenAI. Researchers also found evidence of a reverse proxy providing access to compromised accounts.
The economics are fairly straightforward. Somebody acquires the credentials, other people consume the service, and the account owner gets the bill. Sysdig called it LLMjacking.
By July 2026, its JADEPUFFER investigation described an intrusion that explicitly searched for OpenAI, Anthropic, DeepSeek and Gemini credentials alongside cloud keys, cryptocurrency wallets and database secrets. That campaign went on to database extortion, but the credential hunt was part of its opening activity.
AI credentials have become useful loot in their own right. A small application can hold access to resources worth considerably more than the machine it runs on.
That changes how I think about being an uninteresting target. An attacker looking for usable credentials doesn’t need a particular opinion about your business. An account with available capacity and somebody else paying is enough.
The speed can be uncomfortable too. In April, Sysdig observed an attacker exploiting a marimo honeypot less than ten hours after a vulnerability advisory appeared. During a later session, the intruder read the environment file containing decoy credentials and searched for other secrets. That credential-harvesting session lasted under three minutes.
Three minutes was one session within a longer intrusion. Still, it’s a short amount of time for the part that matters to a credential thief.
Once a usable secret has left the machine, subsequent activity can happen elsewhere. Your application’s response times may have very little to say about it.
A canary gives a particular interaction a way to become visible.
The idea is simple: something that looks useful or interesting has a monitored trigger attached to it. A request to a particular URL, for example, or an attempt to use a decoy credential. That interaction produces an event.
Thinkst’s existing Canarytokens show the distinction clearly. An HTTP token reports a request to its URL. Its AWS credential tokens rely on Amazon’s logging infrastructure to report use, with some delay before the alert arrives.
The mechanism matters. A string that looks like an API key has no detection capability by itself. Something observable has to happen.
What appeals to me is the expected behaviour.
A real credential might legitimately be used thousands of times a day. Working out which request belongs to an intruder can mean understanding jobs, deployments, people and changing workloads.
A decoy credential has no job in your application. Its expected use is zero. An attempt to use it therefore starts with a much narrower explanation to work through.
There’s a difference between another scanner probing your public website and somebody attempting to use a credential that existed only in a private location. The placement gives the event context. It can connect activity outside your system to material that was inside it.
That doesn’t establish who caused the interaction. Security scanners, link previews and legitimate automation can trigger some types of canary. Copying a file or reading text offline may produce no event at all. A quiet canary leaves plenty unknown.
But an unexpected interaction can give you a concrete place to start: which token, what happened, and when it was observed.
It may happen after somebody has already gained access. “Early warning” can mean discovering an intrusion before its consequences become obvious, or while there is still an opportunity to understand how far it has gone. The timing depends on the trigger and how its evidence reaches you.
The useful property is that the canary’s signal depends on the interaction. It can matter even when the vulnerability that led someone there is unfamiliar.
I’m currently building an open-source canary-token service around the way developers and coding agents work: terminals, repositories and automated workflows. It’s still in early development. The part I keep coming back to is making an event understandable, with the context of what was touched and where it belonged.
There’s something very concrete about an attempted use of a credential none of your software needs.
I’d like to know about that while the application is still happily serving customers.