KNJ Panel ยท Penetration test

We attacked our own panel, then published what we found

A fresh install on its own machine, attacked from the outside with no server access and no passwords. Nothing let us in. Everything we did find is below, with its fix and whether it is still open.

9

Findings, none a break-in

8

Fixed and released

0

Ways in found

10

Attack types that held

Download the full report PDF · 290 KB

Run 2026-10-14 · tested on v0.20.9 · retested on v0.20.12

Security audits Penetration testing

How the test ran

Run by our own team, not a third party, and written up with the same openness as our audits. The point is to show the process and the results, not to claim an outside certificate.

  1. 1

    Install

    A fresh virtual machine, set up the way a customer would.

  2. 2

    Attack

    Outside access only, no server login, no known passwords.

  3. 3

    Fix

    Every finding patched in the product and released.

  4. 4

    Retest

    The same machine, upgraded, attacked again.

  5. 5

    Publish

    The results here, including what is still open.

Where every finding stands

All 9 findings, by outcome.

9 findings
  • Fixed 8
  • Accepted 1
  • Open 0

How serious they were

Nothing critical. Most were tightening, not holes.

High
1
Medium
1
Low to Medium
1
Low
3
Informational
3

The one High was an installer failure on common cloud images, not a security hole.

Every finding

Ordered by how much we cared. Nothing is hidden, including the one we chose to leave.

SEC-5 Medium Fixed

A login ban that reached every port

What we found

Five failed panel logins banned the sender from the whole server, including SSH and customers' websites. A shared office address could take a customer's own site offline for its visitors.

What we did

The ban now covers only the panel's own ports. Verified: after repeated failed logins the panel ports refuse the sender while websites and SSH stay reachable.

SEC-8 Low to Medium Fixed

Forgot-password revealed which emails are registered

What we found

The form answered differently for a known and an unknown address, so anyone could check whether a person had an account.

What we did

Both get the same reply, and one source address can no longer try many addresses quickly. Verified with known and invented addresses.

SEC-2 Low Fixed

Browser safety headers missing

What we found

The panel sent three standard protective headers but not a content policy, a referrer policy or a permissions policy.

What we did

All three are now sent on every panel page. The content policy is a baseline; a stricter one that limits where scripts load from is planned.

SEC-3 Low Fixed

phpMyAdmin is identifiable from outside

What we found

The database tool's address redirected to the account login, which confirmed it was installed, and behind that redirect the whole application was reachable from the internet. Using it still needed a valid account login.

What we did

Nothing under the tool's address answers without a signed-in database session, so a stranger gets the same plain "not found" as for any address that does not exist, including the folder, its pages, scripts and themes. Customers still open it with one click from their account panel. Verified from outside on a development server and on our own production server.

SEC-7 Low Accepted

Session cookie is SameSite Lax, not Strict

What we found

Strict is slightly tighter against cross-site requests.

Where it stands

Kept on purpose: Strict would drop the login session when a customer arrives through single sign-on from their own domain. Every state-changing request is already protected by a request token.

SEC-1 Informational Fixed

Web server version in every response

What we found

Each response named the exact web server version, which helps an attacker pick an exploit.

What we did

The version is no longer shown, in headers or on error pages.

SEC-9 Informational Fixed

Version printed on the default error page

What we found

The default web page error also printed the version.

What we did

Fixed together with SEC-1 and verified on every public port.

SEC-10 Informational Fixed

The API told strangers which routes exist

What we found

A real API address answered "sign in required" while a made-up one answered "not found", which let anyone map the API.

What we did

Every unauthenticated request to the API now gets the same answer.

BOOTSTRAP-1 High Fixed

Installer failed on standard cloud images

What we found

On Ubuntu cloud images the installer stopped at its disk quota step, so the panel could not be installed at all. An availability problem, not an exploit.

What we did

The installer now detects the filesystem's built-in quota and uses it. The fix was in place before the test machine was built.

What we couldn't break

Attacks we tried that went nowhere. This is the part that matters most.

Login brute force

Five attempts a minute, then blocked at the network level too.

Account guessing at login

An unknown user and a wrong password get the same message.

Forged requests (CSRF)

A missing, empty or wrong token was refused every time.

Session handling

A new session at login, and the old one dead after logout.

Reaching other accounts

Guessed account numbers returned nothing.

Path traversal

Attempts to read files outside the allowed set were refused.

Extra form fields

Fields like "role" and "is_admin" were ignored.

The API

A logged-in web session does not grant API access.

Exposed files and tools

Setup page locked, debug tools absent, secrets files refused.

Verb tampering

Method overrides still need a valid request token.

Read the full report

The public summary as a PDF.

See our security audits

26 audit rounds on the live build, all published.