ZAP job started failing

[Jack Heslop]

Hi,

We are using the action-af action in a GitHub workflow to attack our frontends.

This runs nightly, and had been consistently completing successfully until the other night when we started seeing:

Automation plan failures:

Unexpected error Cannot invoke "org.zaproxy.zap.extension.ascan.ActiveScan.isStopped()" because "scan" is null - see log for details

I have added a script to our automation framework to find the number of usable nodes in the site tree after running the spiderClient, of which there are 23.

I don't believe we have merged anything into our frontends recently that would cause this, particularly for both frontends to start exhibiting the same failure.

I have dropped the docker_name to point at version 2.16.1, and other than a "ZAP is Out of Date" alert that scan passed as before.

Has something changed in the 2.17.0 release perhaps? Or off the top of your head is there something else we should be checking in the site tree to find the smoking gun?

Thanks in advance,

Jack

[thc202]

Hi,

I think the authentication insights causing the active scan to be
stopped, that exception is a bug/side effect of that though.
https://www.zaproxy.org/docs/desktop/addons/insights/insights-list/

If you are generating the report it should show the insights by default,
note that you will have to set the report job to have `alwaysRun: true`
to ensure that the report is still generated.
https://www.zaproxy.org/docs/desktop/addons/automation-framework/#gen-options

Best regards.

[Jack Heslop]

Thank you. I have added the alwaysRun so I can see those insights. You are correct - it's auth related.

"Percentage of authentication failures: 100%"

But I'm spitting out my frontend logs in the workflow and can see they are returning 200s, which can only happen if authenticated. Every page in the frontend has a sign out link so am using loggedInRegex: \QSign out\E. Could this be causing issues?

Regards.

[Jack Heslop]

For reference I am using a context with browser based authentication. TARGET is the landing URL of the frontend. Prior to authentication this redirects to a login page with a callback to the TARGET upon successful login.

authentication:
  method: browser
  parameters:
    loginPageUrl: ${TARGET}
    loginPageWait: 10
    browserId: firefox-headless
    stepDelay: 0
    diagnostics: false
    steps: []
  verification:
    method: poll
    loggedInRegex: \QSign out\E
    pollFrequency: 60
    pollUnits: requests
    pollUrl: ${TARGET}
    pollPostData: ""

[Jack Heslop]

I've uploaded the zap.log as part of the workflow and it seems ZAP is able to resolve the use of docker_env_vars in some part of the automation framework plan but not all. Is this a bug?

- name: ZAP scan
  uses: zaproxy/acti...@v0.2.0
  env:
    TARGET: ${{ inputs.target }}
  with:
     plan: '.zap/plan.yml'
    cmd_options: '-port 8888'
    docker_env_vars: |
      TARGET

Resolves here

2026-05-11 15:01:08,621 [ZAP-Scanner-0] INFO  AuthUtils - Authentication failure: http://localhost:3001

Does not resolve here
2026-05-11 15:01:08,634 [ZAP-Scanner-0] WARN  AuthenticationMethod - Failed sending poll request to ${TARGET}/
org.apache.commons.httpclient.URIException: incorrect path
at org.apache.commons.httpclient.URI.setRawPath(URI.java:2901)
at org.apache.commons.httpclient.URI.parseUriReference(URI.java:2046)
at org.apache.commons.httpclient.URI.<init>(URI.java:183)
at org.zaproxy.zap.authentication.AuthenticationMethod.pollAsUser(AuthenticationMethod.java:412)
at org.zaproxy.zap.authentication.AuthenticationMethod.isAuthenticated(AuthenticationMethod.java:334)
at org.zaproxy.zap.authentication.AuthenticationMethod.isAuthenticated(AuthenticationMethod.java:246)
at org.zaproxy.zap.users.User.isAuthenticated(User.java:253)