Malformed `calls` (invalid method names / bad `__lazyLoad` params) throw reportable 500s instead of a quiet 419

Livewire version

v4.4.2 (same failure mode on current 4.x as of 2026-09-08)

Laravel version

v13.x

PHP version

8.5.8

Browser and operating system

Not browser-specific (server-side). Observed from automated probes against public pages; reproduced by posting a crafted Livewire update body.

Describe the issue you're experiencing

Not a security issue. Nothing is exposed or bypassed. The problem is the failure mode. Automated scanners fuzz Livewire update payloads by putting garbage in components[].calls — e.g. method: "|", non-string methods, or __lazyLoad with params like ["|"] instead of a base64 JSON snapshot. Those requests currently throw reportable exceptions (HTTP 500 / error tracker noise) where the intended posture — matching typed-property scanner handling — is a quiet 419.

Livewire already distinguishes scanner-injected property TypeErrors and abort(419)s them outside debug (HandleRequests / setComponentPropertyAwareOfTypes, see #10211). There is no equivalent gate for calls:

// HandleComponents::callMethods()
if (! in_array($method, $methods)) {
    throw new MethodNotFoundException($method);
}

So method: "|" becomes MethodNotFoundException and lands in application error reporting. Invalid __lazyLoad params similarly blow up later (checksum / array-offset ErrorException) instead of being rejected as a malformed payload.

This is the same class of production noise as #10685 / #10683 — probes against public Livewire endpoints — just aimed at calls instead of updates.

Related app-side workaround we use today: ignore reporting when a call method is not a valid PHP identifier, or when __lazyLoad’s first param is not a base64-decoded JSON array snapshot. Prefer the framework to quiet-reject these the way it already does for wrong-type property updates.

Code snippets to reproduce the issue

use Livewire\Component;
use Livewire\Livewire;
use Livewire\Exceptions\MethodNotFoundException;

$component = new class extends Component
{
    public function render(): string
    {
        return '<div></div>';
    }
};

$testable = Livewire::test($component);

// Simulate a probe call: method name is not a PHP identifier.
// In a real update POST this is components[0].calls = [{"method":"|","params":[],"metadata":[]}].
try {
    $testable->call('|');
} catch (MethodNotFoundException $e) {
    // Actual (production, app.debug=false): reportable 500 / error tracker alert
    // Expected: quiet abort(419), same as scanner TypeErrors on property assignment
}

// Second shape: __lazyLoad with a non-snapshot param (e.g. "|").
// components[0].calls = [{"method":"__lazyLoad","params":["|"],"metadata":[]}]
// Actual: ErrorException from checksum / offset access while decoding the mount snapshot
// Expected: quiet abort(419) for a malformed lazy-load payload

Steps:

1. Render any public Livewire component once and capture a valid update URL + CSRF token.
2. POST an update body whose calls entry uses method: "|" (or another non-identifier), with an otherwise valid snapshot.
3. Observe MethodNotFoundException / 500 instead of a quiet 419.
4. Repeat with method: "__lazyLoad" and params: ["|"]; observe a reportable ErrorException instead of a quiet 419.

Valid PHP method names that simply do not exist on the component (e.g. missingAction) can keep today’s MethodNotFoundException behaviour — this report is about payloads that are not plausible method calls at all.

Screenshots/screen recordings

N/A — server-side exception noise from probes.

How do you expect it to work?

Before resolving / invoking a call:

1. If method is not a string matching a PHP identifier (^[a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*$), abort(419) outside debug (same posture as #10211).
2. If method === '__lazyLoad' and params[0] is not a string that base64-decodes to a JSON array snapshot, abort(419) outside debug instead of letting checksum / offset access throw.

That keeps real missing methods reportable while matching the existing scanner soft-path for typed-property probes.

Happy to test a fix against production probe payloads.

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I have provided code samples as text and NOT images.
• I understand my bug report will be removed if I haven't met the criteria above.