Faktory CVE-2026-63404

Exploitation requires: (1) a local unprivileged user account on the target host; (2) Faktory deployed via the official systemd unit file, which runs both Faktory and its redis-server child as root - non-systemd or non-root deployments significantly reduce impact; (3) the ability to write to /tmp, which is world-writable by default on Linux; and (4) Faktory must start or restart after the attacker stages /tmp/redis.conf, providing a reliable window during any reboot or service restart. Exploitation is NOT possible from a remote unauthenticated attacker - local account access is mandatory. Non-default configurations that run Faktory as an unprivileged user under systemd reduce the privilege escalation impact to lateral movement rather than root access.

The CVSS 4.0 score of 7.3 with vector AV:L/AC:L/AT:P/PR:L reflects a realistic assessment: exploitation requires local unprivileged access and a specific timing condition (AT:P) - the attacker must stage the malicious file before Faktory starts or restarts. Despite requiring local access, the impact metrics are all High because full code execution as root is achievable via the Redis loadmodule mechanism. No KEV listing and no public exploit code exist at time of analysis, which tempers urgency somewhat, but the attack path is mechanically straightforward for any local user on a multi-tenant Linux host running Faktory under systemd. The EPSS score was not provided in the source data, so comparative probability ranking against the broader CVE population cannot be stated. The real-world risk is highest in shared hosting or CI/CD environments where multiple unprivileged users share a host and Faktory is managed as a system service - environments that regularly restart services (e.g., after updates or reboots) provide reliable exploitation windows without any race-condition timing skill required.

An unprivileged local user on a Faktory host creates /tmp/redis.conf containing a loadmodule directive pointing to a compiled shared library they have staged in a world-readable directory, then waits for a routine system reboot or Faktory service restart. When Faktory's bootstrapper runs, it finds the pre-existing /tmp/redis.conf, accepts it verbatim, and passes it to redis-server running as root; Redis loads the attacker's module, granting them a root shell. No public exploit code has been identified at time of analysis, but the technique requires only standard Linux tools and publicly documented Redis module APIs.