JetFormBuilder: invalid nonce with LiteSpeed ESI enabled?

A JetFormBuilder form works for guests but returns an invalid-nonce error for signed-in administrators. In the reviewed incident, LiteSpeed ESI was enabled and the expected field was absent from the affected output. That is different from a security value that exists but has expired. Q1

Why the distinction changes the investigation

Nonces help validate the intended request context. LiteSpeed documents special treatment of time-sensitive values through ESI. Extending a lifetime cannot create a field already missing from the page. Begin by observing the form and request rather than disabling validation. Q2

Use a test copy and a harmless form action. A successful diagnostic submission should not unexpectedly create genuine orders, registrations or customer notifications. Keep the form configuration unchanged while comparing the relevant roles.

Compare roles and generated output

1. Record versions and form identity: Note LiteSpeed, JetFormBuilder and WordPress versions and the form identifier. Use the same draft and destination action throughout the comparisons.
2. Compare guest and affected role: Use separate sessions. First check whether the nonce field exists in the live document, then whether it reaches the submitted request. Presence in the original page source alone does not prove that the browser sends it.
3. Distinguish absent from rejected: If the value is missing, inspect output generation and subsequent document changes. If it exists, compare session state, timing and the form endpoint’s response. Keep actual values private; a public report usually only needs to state whether they are present.
4. Compare ESI on staging: Change only the relevant ESI setting and clear the cache involved in the test. If the difference disappears reproducibly, the integration is narrowed down. This does not establish that all ESI features across the whole website must remain disabled.
5. Check an applicable vendor solution: Match compatibility guidance and supported plugin releases to your installed combination. A snippet written for another version is not automatically a reliable standard repair.

Verify both functionality and validation

After a correction, test the guest, affected role and, where appropriate, a normal customer role again. Check rejection of incomplete input and one successful test action. Nonce validation should remain enabled; bypassing it globally would replace a functional failure with a protection gap.

Retain the before-and-after role comparison. It gives future maintainers a specific regression test, instead of the vague instruction to check whether the form seems to work.

Frequently asked questions

Will increasing the cache TTL help?

Not when the field is missing. First establish whether any security value is generated and submitted.

Does the error prove an attack?

No. An integration failure is a testable explanation for this workflow. A nonce error alone proves neither an attack nor its particular technical cause.

Why is a successful guest test insufficient?

The failure may be specific to a signed-in role. A working guest page does not exercise that route.

Information for assistance

Provide versions, affected roles, the ESI setting and a redacted comparison of output and request. Access tokens and genuine form contents are unnecessary.

KAN KAI WORKS can investigate form output, user role and ESI processing together. Get help with this case.