Object Encryptor Laravel Package

Technical Evaluation

• Architecture fit: keboola/object-encryptor is a PHP crypto utility for encrypting/decrypting serialized values; Laravel applications can consume it via Composer as a library dependency. Release 2.14.2 hardens cipher decoding by calling unserialize() with ['allowed_classes' => false], which prevents attacker-controlled ciphertext from instantiating arbitrary PHP classes during decryption. This is a security-positive change and aligns with secure-by-default deserialization.
• Integration feasibility: Low effort. The release is a patch-level dependency update with no documented API, config, schema, or ciphertext-format change. Existing secrets are expected to decrypt without re-encryption.
• Technical risk: Overall low, with one behavioral edge case to validate. Payloads that encrypt actual PHP objects may no longer hydrate to their original classes and could return __PHP_Incomplete_Class, causing type errors downstream. If the application encrypts only strings, arrays, scalars, or JSON-encoded values, impact is negligible. The security benefit is meaningful where encrypted payloads are stored in databases, queues, cookies, or other semi-trusted channels.
• Key questions: What data types are encrypted today—objects, arrays, strings, JSON? Are any decrypted payloads object instances with expected methods/properties? Are ciphertexts ever user-controlled or stored outside the app’s trust boundary? Is the package a direct dependency or transitive? Do we have representative legacy ciphertexts for regression testing? What PHP/Laravel versions are supported by the package and by our services? Are any services still pinned below 2.14.2?

Integration Approach

• Stack fit: Standard Composer dependency for PHP/Laravel services. No Laravel service-provider changes, database migrations, or infrastructure changes are implied by this release. If the application wraps the package in a service or facade, the wrapper remains unchanged.
• Migration path: Raise the Composer constraint to require at least 2.14.2, update the lockfile, run the application test suite, and deploy. No re-encryption or key rotation is required. If object payloads are found, migrate those payloads to arrays/scalars or explicitly validate decode behavior before rollout; do not re-enable class instantiation via allowed_classes.
• Compatibility: Ciphertext format is unchanged, so existing secrets should decrypt as before. Compatibility risk is concentrated in PHP object hydration behavior, not in the encrypted format. Confirm the package’s supported PHP versions and that all runtime images meet them.
• Sequencing: Inventory direct and transitive usage; add regression tests using representative ciphertexts from each environment; stage the dependency bump; verify decrypt paths and error logs; canary production; then enforce >=2.14.2 across services. If multiple services share encrypted data, update decrypting services before or alongside encrypting services, though no format coordination is required.

Operational Impact

• Maintenance: Low. This is a security patch, not a feature release. Keep the dependency pinned at or above 2.14.2 and include it in routine dependency patching.
• Support: Vendor-supported patch with a clear security rationale. Document the object-payload caveat so support engineers can distinguish expected __PHP_Incomplete_Class failures from unrelated decryption incidents.
• Scaling: No expected performance, storage, or throughput impact. The allowed_classes option is a decode-time hardening flag and does not change ciphertext size or encryption cost.
• Failure modes: Primary failure mode is decryption returning incomplete objects or throwing type errors where code expects hydrated classes. Secondary risk is delayed discovery of object payloads in low-traffic paths. Monitor decryption error rates and application exceptions after rollout. Rollback is technically possible because the format is unchanged, but it reintroduces the deserialization vulnerability; prefer fixing payload shape over rollback.
• Ramp-up: Minimal. A Laravel engineer can perform the dependency update and regression testing. Security review may require evidence that encrypted payloads are non-object or that object payloads have been remediated.