Pterodactyl Addon Laravel Package

Getting Started

This is a Pterodactyl panel addon, so everything happens inside your existing /var/www/pterodactyl Laravel app — you are not standing up a new service.

Upgrade first, ask questions later. v0.1.4 patches a CVSS 9.9 vulnerability affecting every install on 0.1.3 or earlier:

cd /var/www/pterodactyl
composer require pteroca-com/pterodactyl-addon:^0.1.4
php artisan optimize:clear

Confirm what you actually have before and after — don't trust the lockfile alone:

composer show pteroca-com/pterodactyl-addon
php artisan route:list --path=api/application

Where to look first, in this order:

1. Read GHSA-77vh-c4jh-rv29 in full — the fix description tells you exactly what was exploitable, which tells you what to check for evidence of exploitation.
2. The addon's routes/api.php (now wrapped in Pterodactyl's application-api middleware) — this is the surface that changed behaviour.
3. Any config touching SSO token TTLs and the SSO signing secret.

First use case — the post-upgrade audit. This is not optional cleanup, it's the actual remediation:

// tinker, or a one-off artisan command
User::where('root_admin', true)->get(['id', 'email', 'created_at']);

Compare against your known-good admin list. Then review account API keys attached to administrator accounts and revoke anything unrecognised. If you ran ≤0.1.3 on a publicly reachable panel, treat credential compromise as a possibility rather than a hypothetical.

Requirements: Pterodactyl 1.11+ (release tested against 1.11.11 and 1.15.1). Your PteroCA Application API key needs users read and write — if PteroCA can already create users, you have this.

Implementation Patterns

Let application-api do the authorisation work. The addon's /api/application/* routes now sit behind Pterodactyl's own admin middleware. That is the correct layer — don't reimplement admin checks in your own controllers or add redundant Gate calls around them. If you have a wrapper service, pass it through and handle the 403.

Provision with an admin-scoped key, and scope it deliberately. Creating or deleting user API keys now requires both users write permission and a root_admin account. Concretely: your PteroCA service account must be an admin. That's a real privilege escalation of the integration, so:

// .env on the PteroCA side — never in the repo
PTERODACTYL_API_KEY=...
PTERODACTYL_API_URL=https://panel.example.com

Rotate this key on the same schedule as any other admin credential, and audit its usage.

Handle 422s, not just 500s. Input to the key endpoints is now validated, so malformed payloads return validation errors instead of blowing up. If your client code did if ($response->status() === 500) { retry(); }, rewrite it:

$response = Http::withToken(config('pterodactyl.api_key'))
    ->post("{$base}/api/application/users/{$id}/api-keys", $payload);

if ($response->unprocessable()) {
    // surface $response->json('errors') — field-level validation
}

Same treatment for deletes. The HTTP 500 on user API key deletion under Pterodactyl 1.11+ is fixed in this release. If you had a workaround (raw DB delete, retry loop, swallowing the error), remove it — it's now masking a working endpoint.

SSO: two hard requirements plus a redirect rule.

• The SSO token must carry an expiry. Tokens without one are rejected.
• The signing secret must be configured. An empty secret is now a failure, not a fallback.
• Post-login redirects are restricted to same-site paths. Keep the redirect parameter relative:

// works
'/server/' . $server->uuidShort
// rejected
'https://evil.example.com/steal'
'//evil.example.com'

If you generate SSO links from another app, validate the redirect target on your side too — the addon rejecting it is a second line of defence, not a first one.

Pin and audit in CI. This is a 0.x package; ^0.1.4 is fine for patch-level security uptake, but consider an exact pin in production and let Renovate/Dependabot raise the PR. Add composer audit to the pipeline, and run your integration tests against both Pterodactyl 1.11.x and 1.15.x since the release explicitly covers both.

A cheap recurring guard. Schedule a check for unexpected admin creation and alert on it — this is the exact signal the advisory tells you to look for:

// App\Console\Commands\AuditPanelAdmins
$unexpected = User::where('root_admin', true)
    ->whereNotIn('email', config('panel.expected_admins'))
    ->pluck('email');

if ($unexpected->isNotEmpty()) {
    // log + notify
}

Gotchas and Tips

php artisan optimize:clear is not cosmetic here. The middleware change lives in the route definition. A cached route/config file will keep serving the old, unauthenticated routes and you'll believe you're patched when you aren't. Clear it, then verify with route:list that application-api is actually attached.

Expect 403s after upgrading — that's the fix working. Any non-admin API key or internal script that previously reached /api/application/* will now be rejected. Search your logs for 403s on those paths in the first 24 hours; each one is either a misconfigured integration or a previously-silent privilege problem you now have to resolve properly.

"No configuration changes needed" ≠ "no operational changes." The upgrade command is a one-liner, but the access model tightened: admin-only routes, root_admin for key management, mandatory SSO expiry and secret, restricted redirects. Deploy the code, then re-verify each integration path end-to-end rather than assuming green CI means working SSO.

Empty SSO secret is a silent outage waiting to happen. If your secret comes from an env var, confirm it's set in every environment including staging — the hardened endpoint turns a missing secret into a hard failure rather than a degraded login.

Don't conflate an empty API-key list with "no compromise." Keys could have been created and deleted, or used without leaving a key behind. Cross-reference panel access logs against your expected admin activity for the window you were on ≤0.1.3.

This is still a 0.x addon. Breaking behaviour changes between minor versions are legitimate under semver. Treat every release note as potentially load-bearing, keep the version pinned, and read advisories directly — the changelog summary is not a substitute for the GHSA text.

Extension point worth knowing: because the addon defers to Pterodactyl's native application-api middleware, anything you already do for Pterodactyl admin API security — key rotation policy, IP allowlisting at the proxy, rate limiting, audit logging — applies here for free. Lean on the existing panel infrastructure instead of building addon-specific controls.