If you discover a security vulnerability in CacheKit, please report it responsibly.
Do not open a public issue.
Instead, use GitHub's private vulnerability reporting to submit your report. We will acknowledge receipt within 48 hours and provide a timeline for a fix.
| Version | Supported |
|---|---|
| 0.x | Yes |
The CachekitIO backend transmits cache keys as a single URL path segment (/v1/cache/{key}, …/{key}/ttl, …/{key}/lock). Keys are percent-encoded with encodeURIComponent; a key that is exactly ., .., health, ttl or lock is rejected with a ConfigurationError before any request is built (protocol spec/saas-api.md § Cache-Key Path Encoding, rule 2): the WHATWG URL parser behind fetch removes literal and percent-encoded (%2E) dot segments before the request reaches the wire, and the other three words are live route tokens at that path level. Every other key — including a:.. and every canonical ns:… key — is sent percent-encoded as a single path segment and decodes once server-side to the original key.
This policy covers the @cachekit-io/cachekit and @cachekit-io/cachekit-core-ts packages. For issues with the CacheKit SaaS platform (api.cachekit.io), contact security@cachekit.io.