Only the latest release gets security fixes. Older versions are not patched, upgrade first and check whether the issue still exists.

phpCacheAdmin is an administration tool for cache servers that normally sit next to the application, usually on localhost. It is configured with the credentials of those servers, so anyone who can open the page can do to the cache whatever the server itself allows. That is the point of the tool, not a defect in it.

There is no login page until you define users in authusers. This is deliberate: most installations run it behind something that already handles access – a reverse proxy with its own authentication, the web server's .htpasswd, a VPN, an SSH tunnel, or a private network - and forcing a second login on top of that only gets in the way.

Whether the dashboard is reachable by anyone else is therefore a deployment decision. Options that ship with it:

• authusers - the built-in login page. Passwords can be password_hash() hashes.
• readonly - blocks every destructive action and removes the consoles.
• console - set it to false to remove the Redis and Memcached consoles on their own.
• redisblockedcommands - extra commands to refuse in the Redis console.

The Docker examples publish the port to 127.0.0.1 for the same reason.

The consoles exist to run commands against the server, so most of what they can do is by design – the same as the SQL tab of a database tool. Commands that execute code on the server (EVAL and the rest of the Lua and functions family, MODULE LOAD) are always refused because those turn cache access into code execution on the host. Anything else can be refused with redisblockedcommands, and the whole feature can be removed with console => false.

Open an issue, or write to robo@kelcak.com if you would rather discuss it privately first. Include the version, the configuration it happens with, and what an attacker gains.

• Bypassing the login page while authusers is set, or an action that escapes readonly.
• CSRF, XSS (including from a value stored in the cache), or anything that lets one dashboard user act as another.
• Path traversal, arbitrary file read or write, code execution that does not require console access.
• Leaking the configured server credentials to someone who cannot already read them.

• No authentication in the default configuration, or a dashboard exposed to a network without it. See above.
• Commands run in the console, or the data the dashboard can reach on servers it is configured for. Use readonly, console => false or redisblockedcommands if the people with access should not have that.
• Weaknesses of the cache server itself, e.g., a Redis that allows CONFIG SET dir, runs as root, or has enable-module-command turned on. Report those to the server's maintainers.
• Findings from a scanner with no working proof, and reports about dependencies that are only used for development.