We have configured ip rate limit and we can see only hits, action taken things. But we are unable to see ip rate limit logs.

However, we still have problems with the drop if there are too many requests.

The configured audit log message is shown in the log.

Only the drop is not carried out.

We also do not see any hits or sessions in the limit identifier.

Hits and Action Taken are not counted up.

We have set the threshold to 1 and the time Slice to 1000000 for testing but no drop.

The audit message is written but the drop does not occur.

A test policy with TRUE as expression works.

Many thanks for your help

Sven

It is about adapting the Netscaler configuration against rate limiting attacks that you might incur some day by using an automation software called n8n.

Medium

After implementing alot of WAF, i see that there is alot of scans of known attacks.

10 of 11 requests might be blocked and 1 gets through.

Is there a way (maybe with variables) to add a client src ip to a temporary banned list, if a specific ip has had 2(or higher) number of blocks within a timespan of 5 mins?

1 solution could be to redirect the user to a landing page behind a LBVS, and have some magic here. If you had hit this vServer, you have done something you shouldnt... although that would require the user/bot to follow the redirect that NS is sending, and they are properly not going to do that.

Is there a way to test based on the outcome of a WAF policy in the PI-expressions?

In recent weeks, several CVEs have been disclosed for Microsoft SharePoint, exposing organizations to remote code execution and authentication bypass risks. NetScaler has released WAF signatures to protect against these vulnerabilities.

Overview

On July 8, 2025, Microsoft announced CVE-2025-49704 and CVE-2025-49706 initially discovered by Viettel Cyber Security researchers at the Pwn2Own hacking competition in Berlin. The researchers demonstrated how the flaws could be chained together to bypass authentication and execute code within a SharePoint environment. The latter two i.e. CVE-2025-53770 and CVE-2025-5377` emerged on 20th and 21st July respectively, when attackers demonstrated the original patches were inadequate.

The following breakdown summarizes each CVE and how it affects SharePoint environments.

• CVE‑2025‑49704, CVSS-8.8 - An authenticated attacker can execute arbitrary code on a target server due to a critical remote code execution (RCE) vulnerability in Microsoft SharePoint. This flaw arises from unsafe deserialization of user-supplied data, allowing attackers to upload specially crafted payloads that are then processed and executed within the SharePoint application's context.

• CVE‑2025‑49706, CVSS-6.5 - This is a critical authentication spoofing vulnerability in Microsoft SharePoint that allows a remote, unauthenticated attacker to bypass authentication controls and impersonate a legitimate user. Discovered and demonstrated during Pwn2Own 2024 by Viettel Cyber Security researchers, this flaw enables threat actors to initiate requests that appear to originate from a trusted, authenticated identity — even though no credentials are provided.

• CVE‑2025‑53770, CVSS-9.8 - This is a patch bypass vulnerability in Microsoft SharePoint that re-enables remote code execution (RCE) by undermining the fix for CVE‑2025‑49704. Although Microsoft initially addressed the issue by blocking unsafe deserialization in SharePoint’s web components, attackers found that slight modifications to the original exploit could still trigger RCE.

• CVE‑2025‑53771, CVSS-6.5 - This is a patch bypass vulnerability in Microsoft SharePoint that allows an attacker to bypass authentication mechanisms, even after CVE-2025-49706 was originally patched. This means that although Microsoft released an update in July 2025 to fix the original spoofing vulnerability (CVE-2025-49706), this new CVE indicates the original patch could be bypassed through small modifications to the exploit technique.

For additional details on the vulnerabilities, please refer to the official Microsoft blog.

How NetScaler WAF mitigates these CVEs

NetScaler WAF provides layered, signature-based protection designed to immediately detect and block exploit attempts targeting known vulnerabilities.

Version 157 of the NetScaler WAF signatures includes coverage for all four SharePoint CVEs described above. With these signatures in place, customers can mitigate these threats without needing to rely solely on software patch cycles.

Action recommended

To ensure your environment is protected:

1. Confirm you have the latest version (v157) of the NetScaler WAF signatures

2. Verify that WAF protections are enabled and in BLOCK mode for production environments

3. Review your logs and alerting to ensure visibility into blocked CVE-related traffic

Need help configuring or validating protection? Reach out to your NetScaler representative or consult our WAF documentation for step-by-step guidance. Even in air-gapped or restricted environments, NetScaler makes it easy to manually download and apply WAF signature updates. This flexibility ensures strong protection in high-security or regulated deployments — without compromising ease of use. For instructions on how to turn on NetScaler WAF, see the NetScaler WAF deployment guide.

WAF signatures are a key component of NetScaler’s hybrid security model and they can be updated independently of firmware upgrades, enabling faster response times to emerging threats, especially if you’re using NetScaler Console to manage your NetScaler infrastructure, NetScaler console is available both as an on-prem solution and a cloud service and if you have either the Universal Hybrid Multi-Cloud (UHMC) or Citrix Platform License (CPL), you already own entitlements to this capability across all your NetScaler instances.

After enabling this feature, how does one manage it? I don't see anything enabled under Security; customer has an advanced NS license.

Where are the profile/policies, relaxation rules, etc? Is it all CLI then?

I followed the instructions for creating an entraid app registration to work work with netscaler oauth sp.

Jul 10 14:37:12 <local0.info> 172.31.3.151  07/10/2025:12:37:12 GMT vacnstfi31 0-PPE-0 : default AAATM Message 622847 0 :  "OAUTH RESP: ns_aaa_oauth_resp_handler, response code 400 is not 200 OK, bailing out"

Jul 10 14:37:12 <local0.info> 172.31.3.151  07/10/2025:12:37:12 GMT vacnstfi31 0-PPE-0 : default SSLVPN Message 622848 0 :  "AAA Client Handler: Found extended error code 1310727, ReqType 16386 request /oauth/login?code=1 ...

Browser is displaying "Error trying to validate Access Token. Please contact your administrator". OAUTH Server State is "COMPLETE". In EntraID Sign-in Logs I see success. I am pretty sure I copied the client secret correctly.

What can be issues for that "Error trying to validate Access Token"? What is "extended error code 1310727"?

Can anyone help here?

Regards,

We have deployed the WAF together with the Password spraying blocks following this blog:

https://www.citrix.com/blogs/2024/12/13/password-spraying-attacks-netscaler-december-2024/

For the most part it seems to work just fine, but we've noticed that macOS clients with SAC (with the latest version naturally) can't connect if we deploy the rules as it is.

As a clumsy workaround I have just adjusted the policy to include this bit (my patternset is called "ps_legacy_auth_password_spray":

HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS_ANY("ps_legacy_auth_password_spray") && !HTTP.REQ.HEADER("User-Agent").CONTAINS("Macintosh")

This way we can get the macOS' connected, but then of course if the attacker would send a User-Agent HTTP header including "Macintosh" they could still spray the destination environment.

Has anyone else faced the same issue, and if so, have you found a better solution?

Quote

Apr 28 14:02:21 <local0.info> {nsip}  04/28/2025:14:02:21 GMT {hostname} 0-PPE-0 : default APPFW APPFW_SCHEMA_PARAMETER_INVALID 1214 0 :  X 4302-PPE0 - ns-vpn-default-appfw-profile Parameter is invalid as per API Spec: (ns-vpn-spec) for Endpoint: (GET https://{gw-gqdn}/cgi/setclient?java) <blocked>
Apr 28 14:02:22 <local0.info> {nsip}  04/28/2025:14:02:22 GMT {hostname} 0-PPE-2 : default SNMP TRAP_SENT 0 0 :  appfwSchemaParameterInvalid (appfwLogMsg = "X 4302-PPE0 - ns-vpn-default-appf...", nsPartitionName = default)

I just have the very basic AppFw setup for Gateway + the explicit Deny rules for the Password Spraying.

I could see the front page load, but once we try logging in the connection is reset. Disabling the AppFw protection from the AAA global settings instantly fixed this issue (was configured for AUTH and VPN).

Does Citrix Netscaler hasAuto Layer 7 HTTP DOS protection in 14.1?

I mean like auto threeshold based on statistics of the number of the requests seen or if the server starts returning 5xx (nginx returns 503 when the requests are too many) or responds slow.

I was checking netscaler documents and lot of sections say "AS_DEFAULT_DISPOSITION". I couldnt able to find what is the meaning of this. 

XMLDoSAction One or more XML Denial-of-Service (XDoS) actions. Available settings function as follows:

• Block - Block connections that violate this security check.
• Learn - Use the learning engine to generate a list of exceptions to this security check.
• Log - Log violations of this security check.
• Stats - Generate statistics for this security check.
• None - Disable all actions for this security check.

CLI users: To enable one or more actions, type “set appfw profile -XMLDoSAction” followed by the actions to be enabled. To turn off all actions, type “set appfw profile -XMLDoSAction none”. Default value: AS_DEFAULT_DISPOSITION

I was looking for information about the appfw. I was reading the document and I checked that we have multiple options to configure the actions against the XML checks. The actions can be "None", Block", "Learn", "Log", Most of these actions are mentioned as optional. So my question is that if we dont configure these actions what would be the "default value" of the action?

Understanding CVE-2025-24813

CVE-2025-24813 has a CVSS 3.0 Score 9.8 is a path equivalence vulnerability in Apache Tomcat, a widely used open-source web server and servlet container. This flaw arises from improper handling of file paths containing internal dots (e.g., file.name), which, under specific conditions, can lead to unauthorized viewing of sensitive files, injection of malicious content, or even remote code execution. The vulnerability affects Apache Tomcat versions from 9.0.0.M1 through 9.0.98, 10.1.0-M1 through 10.1.34, and 11.0.0-M1 through 11.0.2.

Understanding CVE-2025-1974

CVE-2025-1974 has a CVSS 3.0 Score 9.8 is a critical security vulnerability found in the ingress-nginx controller of Kubernetes, allows an unauthenticated attacker with access to the pod network to execute arbitrary code within the controller's context. This can result in unauthorized disclosure of sensitive information, including Secrets accessible to the controller. Successful exploitation can lead to control over the ingress-nginx controller pod. Due to the pod's often elevated privileges and access to cluster-wide secrets, an attacker could compromise the entire cluster, gain unauthorized data access, and move laterally within the environment.

NetScaler WAF signatures to the rescue

NetScaler WAF serves as a critical line of defense against web-based threats by filtering and monitoring HTTP traffic between a web application and the internet. NetScaler WAF signatures were released in record time to detect and block exploit attempts targeting specific vulnerabilities like CVE-2025-24813 and CVE-2025-1974.

In order to make use of the signatures please update the signatures after making sure the NetScalers are connected to the internet. For networks where NetScalers can’t be exposed to the internet you can download the signatures manually and apply them very easily. To re-iterate, WAF signatures form a part of the hybrid security model of NetScaler and do not require customers to upgrade the firmware which enables a quick turnaround in dealing with such vulnerabilities. Most of our customers who have recently renewed with UHMC or CPL licenses also get this capability on all their NetScaler instances.

In conclusion, as cyber threats continue to evolve, maintaining a proactive security posture is essential. Vulnerabilities like CVE-2025-24813 and CVE-2025-1974 underscore the need for vigilant monitoring and robust defenses. Implementing and regularly updating WAF signatures tailored to these threats can significantly enhance your organization’s resilience against potential exploits.

 NetScaler WAF: Continued Focus on Developing Signatures for Common Vulnerability Exploits

NetScaler WAF has a long history of providing comprehensive protection against web application vulnerabilities. In 2024, we continue our focus on developing signatures for common vulnerability exploits.

Why is releasing signatures for CVE’s important?

Common vulnerability exploits are a major source of risk for web applications. Attackers are constantly looking for new ways to exploit these vulnerabilities, and it is important to have a web application firewall (WAF) that can block these attacks. Additionally, signatures prevent the need for upgrading NetScaler firmware to tackle CVE’s.

How does NetScaler WAF protect against common vulnerability exploits?

NetScaler WAF uses a variety of techniques to protect against common vulnerability exploits, including:

• Signature-based detection: NetScaler WAF has a large database of signatures for common vulnerability exploits. These signatures can be used to identify and block attacks.
• Heuristic detection: NetScaler WAF uses heuristic detection to identify and block attacks that are not covered by signatures.

Continued Progress in 2024

In 2024, NetScaler released 181 signatures to protect against 146 CVEs, reducing the need for security administrators to create unique policies for common vulnerabilities. NetScaler maintains a consistent effort to release signatures regularly, as shown in the breakdown of signatures released throughout 2024.

NetScaler released signatures in 2024 to address high severity CVEs in several widely used products and services. Some of them are as follows:

Commonly used products, including AI-based applications, are susceptible to attacks such as SQL Injection, as shown in the list above. NetScaler releases WAF signatures every two weeks to address these threats. It is recommended to stay informed about the latest signatures by subscribing to the signature update RSS Feeds. You can find details about which CVEs have been addressed in recent updates in the signature update version documentation here.

NetScaler offers comprehensive application security using signatures to protect application infrastructure. It also provides a deeper understanding of your application's security posture through Security Insights. Security Insights gives detailed analytics and reporting on potential threats, vulnerabilities, and attack patterns, allowing you to proactively identify and mitigate risks and you can configure WAF policies using Terraform/Ansible, refer to this lab to learn more. This combination of signature-based protection and in-depth security insights and automation enables NetScaler to provide easy to use, robust and comprehensive application security.

I have a bit of a strange issue.  I think I understand what is going on, but not how to fix it.

If I run my URL though SSLLabs, it tells me that Strict Transport Security (HSTS) is set to "no."

However I have enabled HSTS using a rewrite action (and I also tried binding the options to my SSL virtual server).  If I run a 'curl' to the root of my application, I don't see the HSTS headers, and I get a "403 Forbidden" response.  If I run a 'curl' to a known static image or page behind my Netscaler, I get the image and the expected 'Strict-Transport-Security' headers.

I assume what's happening is that my WAF is blocking access to "/" and therefore the rewrite action is never getting hit.  Is there a way that I can get SSLLabs to recognize HSTS?  Do I just need to set my WAF to allow access to "/"?

Thanks!

Do you know " how do you collect full body log WAF on Citrix ADC"

I tried on Audit Message Action. But I don't know writen Expression collect full Body log?

Please help

Thanks

Hung Hoang

Looking for a way to edit the regex expression for all learned rules in a bulk rather than manually editing each learned rule before deploying it to relaxation.

I've been finding the documentation on the Bot Management to be very limiting  from Citrix.  I'm looking to implement rate-limiting for a specific application with a global based BOT policy.   For the rate-limit type I can do type: Session which the allows me to specify a specific cookie name to rate-limit off. If an application generates a cookie for each session lets call it "AppSession"  and each cookie for each client has a unique value .  Does the Netscaler itself track each session by the unique value of each individual client for the cookie specified in the policy?  Lets say for example i want to limit to no more than 2 requests over a 1 second interval.  In what scenarios would i specify a rate limit condition? If i wanted to narrow down to a specific url or other indicator?

Client

With regards to the captcha config on the bot management profile.  Is that just a spot where you configure the captcha service you want to use for mitigation  for say IP reputation? or does the netscaler itself perform the captcha?

Thanks,

Auto-update is configure on both appliances in the HA.  The /var/log/bot_auto_update.log shows:
2024-11-06 13:00:04,605 DEBUG Both pre and post SHA is same..
2024-11-06 13:00:04,605 DEBUG Default Bot Signatures are upto date

The var/log/ns.log file shows the same error message:
Command "update bot signature "*Default Bot Signatures"" - Status "ERROR: The command was ignored."

As a last ditch resort I've copied the following files and folders from the primary to the standby unit and reloaded the standby unit:

/nsconfig/bot_signatures/  -  I copied the whole bot_signatures folder to the standby appliance after removing the old folder
/netscaler/default_bot_id
/netscaler/default_bot_signatures.json
/netscaler/default_bot_signatures.schema

Even after copying these files from the primary to the standby manually I have yet to be able to get this to update to the base version of 19 for Bot signatures.

Heres the output from the appliances:
Primary:
> show bot signature
1)      Url: default_bot_signatures.json        Name: "*Default Bot Signatures"
        Creation Date: Wed Sep 18 10:00:07 2024
        Base Version: "19"      Size: 811064 bytes

Total signature Size:   0 bytes
Total Import Size:      2612024 bytes
 Done

Standby:
> show bot signature
1)      Url: default_bot_signatures.json        Name: "*Default Bot Signatures"
        Creation Date: Thu Aug  1 10:00:10 2024
        Base Version: "18"      Size: 820026 bytes

Total signature Size:   0 bytes
Total Import Size:      2612024 bytes
 Done

Is there another spot I should be looking for the default_bot_signatures.json?

Greetings of the day!

Application is not loading properly and not working properly through WAF profile. Application gives a blank page after multiple refreshes of the browser. Checked it in the incognito browser and a different browser. it's showing the same behavior.

Even  after removing block mode also the app is not working but If we unbind the WAF policy and everything started working as expected.

Citrix suggested that unblock the Malformed request action.

Unblocking the Malformed request action is not good idea as per my knowledge. If we unblock the Malformed request action, then impact will be bad for another working WAF profiles why because we are allowing malformed requests as per your request.

Please provide any other solution to fix the issue?

Regards,

Rajkumar M

Does anybody now?

we are currently implementing / finetuning the WAF setup.

we are hosting the same website for hundreds of customers, each customer with his own domain.

I'm a bit stuck on implementing relaxation rules, define something which always works, regardless the domain of the url.

An example of the error I get:

CEF:0|Citrix|NetScaler|NS13.0|APPFW|APPFW_XSS|6|src=1.2.3.4 spt=13771 method=POST request=https://domain/Profile/MyProfile msg=Cross-site script check failed for field __eventtarget\="Bad tag: %# 

=> this is blocked and I would like to create a relaxation rule for this.

This should ignore the domain part of the url and only look ath the path part

so

https://customer.domain.net/Profile/MyProfile - field __eventtarget should be allowed

https://domaincustomer.com/Profile/MyProfile - field __eventtarget should be allowed

in responder policies I can use the variable HTTP.REQ.URL.PATH but can I use something similar in regex expressions in a situation like this?

thanks for your help!

Gijs.