Skip to content

CMS, import, and deserialization boundary batch

Source: GitHub Security Advisories, published/updated 2026-05-05.

This batch is durable because admin-facing import, plugin, package, and integration features are repeatedly crossing from "configuration" into code execution. Treat ZIP uploads, backup restores, package metadata, route parameters, and Java deserialization endpoints as execution boundaries even when they sit behind an admin UI.

Advisories covered

Operator triage

  1. Inventory CMS/admin import paths: plugin ZIP installs, backup restores, package-management APIs, route-driven import actions, and data-source configuration endpoints.
  2. Disable direct install/import endpoints that are internet-facing or reachable by low-trust admin roles until patched.
  3. Hunt for unexpected plugin directories, newly written PHP/Java/Python files, backup restore activity, package folders containing ../, absolute paths, symlinks, or control characters.
  4. For Camel routes, identify endpoints that deserialize objects or accept untrusted transport payloads; move them behind strict authentication and type allowlists.
  5. Treat successful plugin installation, backup restore, or path-traversal writes as host compromise, not just application compromise.

Durable controls

  • Import and plugin features need canonical extraction roots, symlink refusal, extension/type allowlists, archive bomb limits, and post-extraction path verification.
  • Admin APIs should authorize the exact action on the exact resource; "admin panel access" is not enough for super-admin or install privileges.
  • Java integration components should reject native deserialization for network input unless a minimal class allowlist is enforced.
  • Backup restore code must never dereference paths from archive metadata without normalization under an operator-selected restore root.
  • Injection-prone configuration values should be parsed as data, not concatenated into SQL, shell, expression, or template contexts.