SlickStack Exposes You to a Catastrophic Supply-Chain Attack

Update: Jesse Nickles Responds, But the Core SlickStack Security Risk Still Exists

On August 25, 2026, Jesse Nickles published a new response attempting to dismiss the SlickStack security concerns:

https://github.com/littlebizzy/slickstack/blob/faa2092878273d730533b43fe5f4f7c5ccd1f24a/docs/malware-rumors.md

Unfortunately, his response does not fix the underlying problem.

In several places, it actually confirms the architecture I have been warning about.

The current SlickStack root crontab still contains this behavior:

https://github.com/littlebizzy/slickstack/blob/faa2092878273d730533b43fe5f4f7c5ccd1f24a/crons/00-crontab.txt#L99-L116

47 */3 * * * /bin/bash -c 'sleep $((RANDOM % 180)) && { wget -q -4 -t 3 -T 10 -O /tmp/heal-01-cron-minutely https://slick.fyi/crons/01-cron-minutely.txt || wget -q -6 -t 3 -T 10 -O /tmp/heal-01-cron-minutely https://slick.fyi/crons/01-cron-minutely.txt; }; [ -s /tmp/heal-01-cron-minutely ] && grep -q "SS_EOF" /tmp/heal-01-cron-minutely && mv -f /tmp/heal-01-cron-minutely /var/www/crons/01-cron-minutely && chmod 0700 /var/www/crons/01-cron-minutely || rm -f /tmp/heal-01-cron-minutely'

This is not merely "checking for updates."

Every three hours, SlickStack's root crontab contacts slick.fyi, downloads replacement shell scripts, checks whether they contain the string SS_EOF, and then forcefully replaces executable files that will subsequently run as root.

That distinction matters.

The files do not even need to be "missing or damaged"

Jesse describes this system as:

"periodically restores missing or damaged SlickStack cron files"

But the actual root crontab does not appear to establish that the installed cron file is missing or damaged before replacing it.

There is no checksum comparison against the existing file.

There is no comparison against an approved Git commit.

There is no signed release verification.

There is no pinned version.

There is no cryptographic authenticity check.

Instead, every three hours, SlickStack downloads another copy and, if it contains SS_EOF, executes:

mv -f /tmp/heal-01-cron-minutely /var/www/crons/01-cron-minutely
chmod 0700 /var/www/crons/01-cron-minutely

That means a perfectly functional local executable can still be replaced.

This is not merely:

"If something breaks, recover it."

It is a recurring remote replacement mechanism for code that executes as root.

SS_EOF is not a security verification

The so-called validation is effectively:

grep -q "SS_EOF" downloaded-script

That does not verify that the file came from GitHub.

It does not verify a checksum.

It does not verify a cryptographic signature.

It does not verify a release.

It does not verify a commit hash.

It does not verify that the administrator previously approved the code.

A modified script containing:

#!/bin/bash

# arbitrary commands

## SS_EOF

would satisfy that check.

So the effective trust model looks like this:

remote endpoint
      |
      v
downloads shell script
      |
      v
contains "SS_EOF"?
      |
      v
YES
      |
      v
replace local executable
      |
      v
executed as root

For a server-management project, this should concern anyone responsible for production infrastructure.

The root-level trust path goes through slick.fyi

The root crontab explicitly retrieves files from:

https://slick.fyi/crons/...

This matters because slick.fyi is controlled by the project rather than being a pinned immutable artifact source.

Jesse's own response explains that the purpose of slick.fyi is to provide an abstraction layer so the upstream destination can be changed without requiring every SlickStack server to be manually updated.

That is precisely the security concern.

An installed SlickStack server is not simply saying:

I trust this specific GitHub repository.

It is effectively saying:

I trust slick.fyi to decide where future root-executed scripts come from.

Even if:

slick.fyi -> GitHub

today, the entire purpose of that layer is that the destination can be changed later.

That makes control of slick.fyi an extremely powerful supply-chain control point.

If the infrastructure controlling that endpoint, its DNS, redirect configuration, hosting account, or related credentials were compromised, modified scripts could potentially be distributed through an update path that already exists on installed machines.

And those scripts do not execute as a restricted web user.

They execute as root.

Root means full server control

Root is the highest privilege available on a normal Linux server.

A shell script executing as root can potentially:

• read application secrets
• access databases
• access SSH keys
• read private files
• modify websites
• create new system users
• install persistent services
• alter firewall rules
• install additional software
• modify other executables
• delete data
• encrypt data
• exfiltrate credentials
• access customer data stored on the server
• use the server to attack other systems

The point is not that SlickStack is currently performing all of those actions.

The point is that the update architecture delivers code into a context where those actions are technically possible.

That is why authentication of root-executed updates matters so much.

HTTPS and DNSSEC do not solve the problem

Jesse points to HTTPS and DNSSEC as security protections.

They do not address the core issue.

HTTPS answers:

"Did I securely connect to the server controlling slick.fyi?"

It does not answer:

"Is this the exact shell script from the release my administrator approved?"

A legitimate HTTPS endpoint can still return modified content.

DNSSEC protects DNS resolution.

It does not provide code signing.

Neither one proves that a downloaded shell script corresponds to a specific Git commit, release, checksum, or administrator-approved artifact.

For code that will execute as root, the artifact itself should be authenticated.

SlickStack contains a "FORKABLE" repository system

This is where the architecture becomes especially confusing.

Inside:

https://github.com/littlebizzy/slickstack/blob/faa2092878273d730533b43fe5f4f7c5ccd1f24a/bash/ss-functions.txt

SlickStack contains a section literally labeled:

SS-Functions: Mirror Prefixes (FORKABLE)

It then says:

## you should customize the Git mirror prefixes below if you decide to fork SlickStack ##
## after changing these the rest of the paths in ss-functions should work fine ##

## MODIFY THESE IF YOU FORK SLICKSTACK

GITHUB_PREFIX="https://raw.githubusercontent.com/littlebizzy/slickstack/master"
GITLAB_PREFIX="https://gitlab.com/littlebizzy/slickstack/-/raw/master"
SOURCEFORGE_PREFIX="https://sourceforge.net/p/slickstack/code/ci/master/tree"
BITBUCKET_PREFIX=""
GITEA_PREFIX=""

At first glance, this appears to give administrators or fork maintainers control over where SlickStack retrieves its code.

Many downstream paths are then derived from those variables:

GITHUB_00_CRONTAB="${GITHUB_PREFIX}/crons/00-crontab.txt"
GITHUB_01_CRON_MINUTELY="${GITHUB_PREFIX}/crons/01-cron-minutely.txt"
GITHUB_02_CRON_OFTEN="${GITHUB_PREFIX}/crons/02-cron-often.txt"

and:

GITHUB_SS_CHECK="${GITHUB_PREFIX}/bash/ss-check.txt"
GITHUB_SS_FUNCTIONS="${GITHUB_PREFIX}/bash/ss-functions.txt"
GITHUB_SS_INSTALL="${GITHUB_PREFIX}/bash/ss-install.txt"

So an administrator could reasonably believe that changing:

GITHUB_PREFIX="https://raw.githubusercontent.com/MYCOMPANY/MYFORK/master"

would make their server trust their own audited fork.

Unfortunately, that is not a reliable trust boundary.

The file containing your fork setting can itself be overwritten

This is one of the most concerning design problems I found.

09-cron-daily.txt checks /var/www/ss-functions before it sources that file.

It does:

VALIDATE_SS_FUNCTIONS=$(grep 'SS_EOF' /var/www/ss-functions)
OUTDATED_SS_FUNCTIONS=$(find "/var/www/ss-functions" -maxdepth 1 -type f -mmin +720)

The important part is:

-mmin +720

That means after 720 minutes, or 12 hours, ss-functions can be treated as outdated.

Then, instead of using your configured GITHUB_PREFIX, the recovery logic directly hardcodes:

https://raw.githubusercontent.com/littlebizzy/slickstack/master/bash/ss-functions.txt

with hardcoded LittleBizzy GitLab and SourceForge fallbacks.

It then performs:

mv -f /tmp/ss-functions /var/www/ss-functions
chown root:root /var/www/ss-functions
chmod 0700 /var/www/ss-functions

Only after doing that does it execute:

source /var/www/ss-functions

So the flow can effectively become:

your customized ss-functions
        |
        | contains:
        |
        | GITHUB_PREFIX=MYCOMPANY/MYFORK
        |
        v
12 hours pass
        |
        v
09-cron-daily runs
        |
        v
hardcoded littlebizzy/slickstack URL
        |
        v
downloads official ss-functions
        |
        v
mv -f over your ss-functions
        |
        v
your custom GITHUB_PREFIX disappears
        |
        v
LittleBizzy prefixes are restored

This is a serious contradiction with the statement:

"after changing these the rest of the paths in ss-functions should work fine"

The very file containing the customization can itself be replaced through a path that ignores the customization.

The root crontab completely bypasses the "FORKABLE" settings anyway

It gets worse.

The root crontab explicitly says:

## THIS CRONTAB FILE DOES NOT RELY ON SS-CONFIG OR SS-FUNCTIONS

That means the supposedly "FORKABLE" mirror prefixes cannot affect this root recovery mechanism at all.

Instead, the root crontab directly hardcodes:

https://slick.fyi/crons/01-cron-minutely.txt
https://slick.fyi/crons/02-cron-often.txt
https://slick.fyi/crons/03-cron-regular.txt
https://slick.fyi/crons/04-cron-quarter-hourly.txt
...

every three hours.

So even if you successfully change:

GITHUB_PREFIX="https://raw.githubusercontent.com/MYCOMPANY/MYFORK/master"

the root-level recovery path still does this:

GITHUB_PREFIX = your fork
        |
        X
        X  ignored
        X
        |
root crontab
        |
        v
slick.fyi
        |
        v
replacement executable scripts
        |
        v
root

Your fork configuration has no control over that path.

The installer has the same bootstrap problem

The same issue appears in ss-install.

Before it can safely rely on the variables inside ss-functions, SlickStack includes recovery logic that directly retrieves:

https://raw.githubusercontent.com/littlebizzy/slickstack/master/bash/ss-functions.txt

with LittleBizzy GitLab and SourceForge fallbacks.

That means installation and recovery logic can restore the official ss-functions file independently of your configured fork settings.

This creates a circular trust problem:

ss-functions defines where SlickStack should download code
        |
        v
but recovery of ss-functions itself
        |
        v
does not trust those settings
        |
        v
it trusts hardcoded LittleBizzy locations

So the supposed fork setting is not the ultimate authority.

The hardcoded bootstrap paths are.

Hardcoded LittleBizzy repository URLs are widespread

This is not one forgotten line.

Hardcoded references to:

raw.githubusercontent.com/littlebizzy/slickstack/master

appear across many active SlickStack files, including cron scripts and update-related scripts.

Examples include:

crons/01-cron-minutely.txt
crons/02-cron-often.txt
crons/03-cron-regular.txt
crons/04-cron-quarter-hourly.txt
crons/05-cron-half-hourly.txt
crons/06-cron-hourly.txt
crons/07-cron-quarter-daily.txt
crons/08-cron-half-daily.txt
crons/09-cron-daily.txt
crons/10-cron-half-weekly.txt
crons/11-cron-weekly.txt
crons/12-cron-half-monthly.txt
crons/13-cron-monthly.txt
crons/14-cron-sometimes.txt
bash/ss-worker.txt
bash/ss-install.txt

and other installation and recovery scripts.

This means there is no single administrator-controlled setting that appears to establish:

Only retrieve executable SlickStack code from my trusted repository.

Some code paths use the configurable variables.

Others bypass them.

And some of the bypass paths are capable of replacing the very file that defines the configurable variables.

Calling the mirror system "FORKABLE" is misleading from a security perspective

To be clear, parts of the project do honor the fork variables.

For example, ss-check uses variables such as:

${GITHUB_01_CRON_MINUTELY}
${GITLAB_01_CRON_MINUTELY}
${SOURCEFORGE_01_CRON_MINUTELY}

So the fork feature is not completely fake.

The problem is that it is incomplete.

It does not establish a complete trust boundary.

The project effectively has multiple overlapping update systems:

                 +----------------------+
                 | GITHUB_PREFIX        |
                 | "FORKABLE"           |
                 +----------+-----------+
                            |
                            v
                    some update paths


root crontab --------------------------> slick.fyi

09-cron-daily ------------------------> hardcoded littlebizzy GitHub
                                      hardcoded littlebizzy GitLab
                                      hardcoded LittleBizzy SourceForge

ss-install ---------------------------> hardcoded littlebizzy upstreams

That is not a clean or auditable update architecture.

For a project managing production Linux servers as root, this level of duplicated and overlapping trust logic is exactly what should be avoided.

Jesse's own response acknowledges the fundamental trust issue

One particularly notable section of Jesse's response discusses whether LittleBizzy could remotely "take over" a SlickStack server.

His own document describes the answer as:

"essentially yes"

He argues that this is merely the trust relationship created by automatic updates.

But that is exactly why the update architecture matters.

There is an enormous difference between:

signed release
      |
      v
pinned version
      |
      v
cryptographic verification
      |
      v
administrator-approved installation

and:

project-controlled domain
      |
      v
mutable shell script
      |
      v
grep "SS_EOF"
      |
      v
overwrite executable
      |
      v
root execution

Calling the latter "self-healing" does not remove the capability.

SlickStack already proves it can use public repository mirrors directly

Other parts of SlickStack already use a much more transparent recovery approach.

For example, some recovery logic explicitly attempts:

recover from github
recover from gitlab
recover from sourceforge

with direct URLs.

That means there is no technical requirement for the root crontab to depend on slick.fyi.

Even direct GitHub URLs, however, would only partially solve the problem if they continue tracking a mutable master branch.

A secure update mechanism should authenticate a specific artifact.

What SlickStack should be doing instead

A proper update mechanism for software capable of modifying root-executed code should look more like:

signed release
      |
      v
download artifact
      |
      v
verify signing key
      |
      v
verify SHA-256
      |
      v
verify expected version
      |
      v
install

Administrators should also have one authoritative configuration controlling the upstream:

SS_UPSTREAM_REPOSITORY="https://github.com/example/slickstack"
SS_UPDATE_CHANNEL="v2026.08"
SS_AUTO_UPDATE="false"

Every update and recovery path should derive from that setting.

No hidden fallback should silently jump back to another repository.

No bootstrap routine should overwrite the configuration with a different upstream.

No root crontab should bypass it.

Mirrors could still exist for reliability.

But the mirrors should only transport an already authenticated artifact.

They should not determine what code the server trusts.

The central security concern remains unanswered

My warning is not based on the fact that SlickStack performs updates.

The problem is the trust architecture.

SlickStack maintains recurring mechanisms capable of replacing root-executed shell scripts using mutable remote sources.

Some of those sources are controlled through slick.fyi.

Some use hardcoded LittleBizzy repository URLs.

Some use configurable mirror variables.

And some recovery paths can overwrite the file containing those configurable mirror variables.

At the same time, the actual integrity check for certain root recovery paths is simply whether the downloaded file contains:

SS_EOF

That is not cryptographic authentication.

It does not disappear because the mechanism is called "self-healing."

It does not disappear because the source code is public.

It does not disappear because HTTPS is enabled.

It does not disappear because DNSSEC is enabled.

It does not disappear because slick.fyi currently redirects somewhere legitimate.

And it certainly is not solved by a "FORKABLE" configuration system when other privileged update paths bypass that system and can overwrite its configuration.

The fundamental question remains:

Why should a server-management project install a default mechanism that repeatedly accepts mutable shell scripts through project-controlled infrastructure and later executes those scripts as root, without cryptographically verifying that they correspond to a specific administrator-approved release?

That is the issue.

And after years of criticism, it remains present in the project.

Instead of publishing pages attacking the person reporting the problem, I would strongly encourage Jesse Nickles to replace this architecture with a normal, auditable release and update mechanism.

For anyone currently running SlickStack on an important server, I strongly recommend reviewing:

1. What the root crontab downloads.
2. Where those files come from.
3. Which URLs are hardcoded.
4. Which URLs actually honor the "FORKABLE" settings.
5. Whether /var/www/ss-functions can be replaced automatically.
6. Whether your fork configuration survives those recovery paths.
7. Whether downloaded code is cryptographically authenticated.
8. Whether you are comfortable granting these update paths this level of control over your server.