Panel Laravel Package

Technical Evaluation

Architecture fit. Pterodactyl Panel is a Laravel/PHP application that manages game server instances; "eggs" are the configuration templates (docker image, startup command, environment variables, install script) that define a server type. For a team already standardized on Laravel/PHP, the runtime and extension model fit cleanly — the panel is a conventional Laravel app with an administrative surface, queue workers, and a database backend, so existing PHP operational tooling (Composer, migrations, queue/scheduler supervision) applies.

The picture now has two parallel release lines, and that is the material architectural change since the prior assessment:

• 2.0 open beta (v2.0.0-beta.2, 2026-10-14): a single-defect fix restoring egg export/import round-trip fidelity.
• 1.x stable maintenance (v1.15.2, most recent item reviewed): a security release for the "php2shell" family (CVE-2026-109618, CVE-2026-109619). The shipped Docker image moves to PHP 8.3.36 and disables session.upload_progress in php-fpm; non-Docker installs are directed to PHP 8.2.35 or 8.3.36 with all php8.* packages upgraded together.

The critical architectural read: the vulnerability is in the PHP runtime, not in panel code. Remediation lands partly in the image and partly in a php-fpm configuration directive. That means every PHP service in the estate inherits the exposure, and the "architecture fit" answer for the panel is now coupled to our broader PHP base-image and host-patching strategy.

Integration feasibility. Both releases are operationally simple; their implications are not symmetric.

• v1.15.2 is a low-ceremony, high-urgency patch for anyone running 1.x in production: pull the new image, or run the documented apt upgrade path and restart php-fpm. There is no schema change implied and no migration step described.
• v2.0.0-beta.2 remains a round-trip integrity fix on the egg file format, distributed as a tagged Docker image (ghcr.io/pterodactyl/panel:v2.0.0-beta.2), with documented new-install and beta-to-beta paths plus a separate 1.x upgrade guide.

The gap to close: the notes confirm the 1.x image is rebuilt on patched PHP, but say nothing about whether v2.0.0-beta.2's image carries 8.3.36 or the session.upload_progress mitigation. If we are piloting the beta, we must not assume the security fix rode along.

Technical risk. Three risks now dominate, in order:

1. Runtime exposure independent of version line. Choosing 1.x vs. 2.0 beta does not change whether the underlying PHP is patched. Teams often treat "we're on the beta, we'll patch at GA" as acceptable — that reasoning does not hold for a PHP-runtime CVE.
2. Partial-upgrade breakage. The upstream instruction to "upgrade every php package together" is a warning, not boilerplate: mixed php8.* package versions on a host are a known source of extension/ABI mismatch, and a half-applied upgrade can take the panel down harder than the CVE.
3. Behavioral change from the mitigation. Disabling session.upload_progress in php-fpm is a config-level defense-in-depth measure. It can alter or remove upload-progress behavior wherever the application or reverse proxy depends on it. Low probability of user-visible impact, non-zero, and cheap to verify.
4. Lifecycle stage (unchanged). 2.0 remains an open beta — interfaces, schema, and egg format may move between betas, and a bug-fix-only beta is low signal for a go/no-go.

Carry forward from the prior assessment: artifacts exported on earlier betas are untrusted until re-exported and re-validated, since that defect was silent.

Key questions.

• Which line do we standardize on operationally — 1.x (stable, security-maintained) or 2.0 beta (feature track, no support guarantee) — and who owns that decision?
• Has v2.0.0-beta.2's image been rebuilt on PHP 8.3.36 with session.upload_progress disabled, or is the beta line still carrying the vulnerable runtime?
• What is the upstream support window for 1.x now that it is receiving security backports, and how long after 2.0 GA does it continue?
• Do any panel features, our reverse proxy config, or our admin tooling depend on session.upload_progress? What is the observable regression if it is off?
• Are there other PHP services in the estate (internal apps, Composer-based tooling, sidecars) running 8.2 < 8.2.35 or 8.3 < 8.3.36?
• What is the full CVE detail — attack vector, authentication requirement, and whether the panel's admin surface or the node/daemon path is implicated?
• What Laravel and PHP versions does the 2.0 line require, and are those within our supported platform matrix? (1.x is now confirmed at PHP 8.2/8.3; 2.0 is unconfirmed.)
• Is the egg file format stable across 1.x → 2.0 and across 2.0 betas, or is a transformation step required?
• What is the published path and rough timing to 2.0 GA?
• Does the 1.x upgrade guide cover in-place database migration only, or is there a supported rollback?
• Are there API or permission-model changes in 2.0 that would break existing automation around the panel?
• What is the security disclosure policy and advisory history — is there a channel we should be subscribed to rather than discovering releases retrospectively?

Integration Approach

Stack fit. Fits a Laravel/PHP estate without introducing a second runtime. Operational dependencies are the usual ones: a relational database, a queue worker, scheduled tasks, and persistent storage for server data. The unusual element remains that the panel orchestrates Docker on managed nodes, so the blast radius of a panel misconfiguration extends to game-server workloads, not just the web tier.

This release adds a new integration surface at the boundary: base-image and host PHP version control. Whatever we do for the panel should be expressed once, as a standard, not as a one-off ticket.

Migration path. Three distinct paths, sequenced separately:

1. v1.15.1 → v1.15.2 (security): highest priority, lowest ceremony. Docker: pin the new image tag/digest and redeploy. Non-Docker: apt upgrade of all php8.* together, then reload php-fpm and the queue workers. Treat as a planned but expedited change with a restore point.
2. Beta-to-beta (e.g. beta.1 → beta.2): documented, low ceremony, appropriate for a staging pilot. Do not assume the security patch is included — verify the PHP version inside the running container.
3. 1.x → 2.0: explicitly flagged upstream to be tested on a copy of the panel first. Treat this as a project, not an upgrade ticket — copy the database, run the upgrade against the copy, and verify authentication, node/daemon connectivity, server start/stop, and egg import before touching production.

Compatibility. Three concrete checks:

• PHP package coherence: all php8.* packages at one version per host; verify with a version inventory sweep rather than per-package assumption.
• session.upload_progress dependency: confirm whether the admin UI, our reverse proxy, or any custom tooling reads upload-progress state. If yes, test explicitly; if no, record that finding so the directive is not silently re-enabled later.
• Egg round trip: re-export our egg library from a beta.2 instance and import into a scratch panel; this doubles as a format-compatibility check against existing 1.x eggs.

Sequencing.

1. Patch 1.x production to v1.15.2 first. Security remediation outranks the beta evaluation; it also removes the excuse to rush the 2.0 decision.
2. Sweep the wider estate for PHP instances below 8.2.35 / 8.3.36 and remediate on the same standard.
3. Confirm (in writing) the PHP version inside the v2.0.0-beta.2 image; if unpatched, block the beta pilot until it moves, or accept a documented, time-boxed exception on an isolated staging panel only.
4. Pin to explicit tags or image digests — never a floating tag — and record them in our dependency inventory.
5. Stand up a staging panel on the beta from a production copy; run the 1.x upgrade guide end to end.
6. Validate egg export → import round trip plus a representative sample of real eggs.
7. Exercise the operational surface: node registration, backup/restore, user provisioning, API tokens, and an admin file upload.
8. Only then schedule a production 2.0 window, with a documented restore point.
9. Re-run the round-trip and PHP-version checks on every subsequent beta.

Operational Impact

Maintenance. Two recurring streams instead of one: a security-patch stream on 1.x (irregular, urgent) and a beta-cadence upgrade stream on 2.0 (regular, no LTS guarantee). Budget capacity for both, and do not let the beta evaluation consume the attention the security stream requires. Image pinning plus written re-validation checklists convert each stream from ad-hoc patching into routine maintenance. Add PHP base-image currency to the platform's standing inventory — this release proves we cannot rely on discovering runtime CVEs through package release notes.

Support. Upstream documentation is versioned and splits v2 from 1.x, so internal runbooks must cite the v2 paths explicitly — mixed-version documentation is a predictable source of operator error. First-line support needs a new triage rule: any report of failed uploads, session weirdness, or 500s immediately following a PHP patch goes straight to platform engineering, not the helpdesk. Anything touching node/daemon connectivity or server file integrity escalates as before.

Scaling. Unaffected. The panel's scaling profile is driven by managed node and server count, queue throughput, and database size. Neither the egg export fix nor a PHP point-release changes that. One secondary note: disabling session.upload_progress removes a small amount of session-write overhead per upload — negligible, and not a reason to adopt or reject the change.

Failure modes.

• Unpatched or partially patched PHP runtime — the new top risk. A host upgraded package-by-package, or a sidecar/secondary PHP service left behind, retains the CVE while appearing "patched" in the panel's own changelog. Mitigation: version-inventory sweep and a written per-host remediation record, not a per-application one.
• Beta image carrying the vulnerable runtime. Mitigation: verify PHP version inside the container before pilot use; make it a gate, not a check.
• Silent artifact corruption (the defect fixed in beta.2): exports that appear successful but fail on import. Mitigation: mandatory round-trip validation before any egg is promoted into shared config.
• Upload-progress regression from the session.upload_progress mitigation. Low severity, high visibility if it hits an admin workflow. Mitigation: explicit test of the admin upload path post-patch.
• Beta drift: schema or format changes between betas breaking a previously working upgrade. Mitigation: pinning, staged upgrades, restore points.
• Half-completed 1.x → 2.0 upgrade: still the highest-severity scenario, since panel and node/daemon versions can desynchronize. Mitigation: rehearse on a copy; never split the upgrade across a partial fleet without an explicit compatibility check.
• Unpinned image pull: silently moving to an unreviewed build. Mitigation: digests in deployment manifests. Note the inverse hazard too — a pinned digest now blocks an emergency security pull if the runbook does not say how to re-pin under time pressure.

Ramp-up. Low for anyone with Laravel experience, moderate for the domain layer. Three audiences now:

• Platform engineers — deployment and upgrade mechanics, plus the PHP runtime patch runbook (image rebuild vs. apt path, package coherence, php-fpm reload, queue worker restart).
• Administrators — the egg model and the export/import workflow.
• Security/ops on-call — how to recognize a runtime-CVE advisory, verify remediation across hosts and containers, and re-pin images under time pressure.

A single half-day session covering the egg lifecycle plus the upgrade rehearsal still gets a small team productive; add a 30-minute tabletop on the PHP patch path. The 1.x upgrade guide remains the primary ramp-up artifact and should be walked through hands-on, not just read.