Deployment: Invicti Platform on-demand, Invicti Platform on-premises
The login sequence is invalid
When your scan shows this alert, Invicti Platform couldn't play back the login sequence successfully for three consecutive attempts. The scan is running unauthenticated, which means authenticated pages and their vulnerabilities are missing from the results. This document explains how to diagnose the most common causes so you can restore successful authentication.
If you're still setting up session detection or haven't configured a session pattern yet, start with the Session detection document. If setup is complete but you can't identify a valid session pattern, see LSR advanced troubleshooting. This document applies once the login sequence is configured and the scan itself starts showing the alert.
To analyze log files, Klogg is a free cross-platform log analyzer that handles large files well. For instructions on how to download logfile.csv, refer to the Download scan logs document.
When defining a login sequence, make sure proper Restrictions and a proper Session detection are in place. This keeps the scan authenticated and improves coverage.
Why this matters
An invalid login sequence means Invicti Platform runs the scan without authenticating. Authenticated pages and the vulnerabilities they expose are invisible to an unauthenticated scan, giving you an incomplete picture of your target's risk. Resolving the issue ensures your scans cover the full attack surface.
Troubleshooting
Work through the scenarios below in order. Each one describes what you'd see in the scan logs and what to do about it.
1. Verify that manual playback is successful
Login flow elements may have changed since you defined the login sequence - particularly for scheduled scans.
Recommended action: Edit the login sequence, verify all steps are correct, then run manual playback and confirm it completes successfully.
If manual playback is successful and session detection also passes, but The login sequence is invalid still appears as a scan result, check the following scenarios.
2. Target server is throttling or blocking requests
During scans, Target server may start responding with 403:
X-Sent-By: Acunetix-LSR/65535
GET /vis.../ HTTP/1.1
Host: test.vis...
...
HTTP/1.1 403 Forbidden
Server: awselb/2.0
Content-Type: text/html
...
or 429 status codes.
Recommended action: Search in
logfile.csvfor403or429status responses. Check for any rate limiting or access restrictions on the target side — if a WAF is blocking LSR playback, refer to the Web Application Firewall detected document. Try lowering the scan speed — see Reduce scan times for instructions.
3. Target server is becoming unresponsive
There could be times when the Target server may start showing an error page (for example, a 404 - File or directory not found), like the example below:
X-Sent-By: Acunetix-LSR/65535
GET / HTTP/1.1
Host: portal-...
...
HTTP/1.1 404 Not Found
Content-Type: text/html
...
Recommended action: Search in
logfile.csvfor404status responses related to the Login flow. Review the target server configuration and available resources under load. Try lowering the scan speed — see Reduce scan times for instructions.
4. SSO login flow involved (Microsoft Entra ID)
Open logfile.csv and search for WWW-Authenticate: Negotiate. A response like the one below from the identity service means the authentication flow broke during playback.
logfile.csv example:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
Recommended action: Set the User-Agent to
WVS/12.0, or add an action step to the LSR to click Use a certificate or smart card.
5. Check if session was gained
Run this check after confirming all action steps played back successfully during the scan (verify in browser.log).
Open logfile.csv and search for isInSession: [1].
If you see isInSession: [1] followed by isInSession: [0] and then isInSession: [1] again, this is expected behavior — the scanner lost the session and reauthenticated successfully. This can happen multiple times throughout a scan. Only investigate further if isInSession: [1] never appears at all.
If not found:
- The Session pattern may be invalid. Edit the sequence, click Play, go to the Session detection tab, and click Check pattern.
- If Check pattern fails, find a different pattern (try auto-detect, "Detect while navigating", or enter one manually).
- If Check pattern succeeds, the scanner may be failing to track Cookies or Session headers.
To verify whether the session checking request was made successfully, search logfile.csv for X-Sent-By: Acunetix-LSR/65535, then find the lsr-check line that follows:
logfile.csv example:
X-Sent-By: Acunetix-LSR/65535
X-Sent-By: lsr-check #LSR
Inspect that request to confirm it includes the required Cookies and/or Session Headers.
Need help?
Invicti Support team is ready to provide you with technical help. Go to Help Center