# What is New in Wallarm Node 6.x and 0.14.x This changelog covers updates for NGINX Node 6.x and Native Node 0.14.x+. If upgrading from an older version, refer to [this](https://docs.wallarm.com/updating-migrating/older-versions/what-is-new.md) document. For the detailed changelog on minor versions of the Wallarm Node, refer to the [NGINX Node artifact inventory](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) or [Native Node artifact inventory](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md). This release introduces key architectural improvements aimed at enhancing performance and maintainability of the Wallarm Node. These updates also lay the groundwork for upcoming features. ## Replacing Tarantool with wstore for postanalytics Wallarm Node now uses **wstore, a Wallarm-developed service**, instead of Tarantool for local postanalytics processing. As a result, the following changes have been introduced to NGINX Node: * [All-in-one installer](https://docs.wallarm.com/installation/nginx/all-in-one.md), [AWS](https://docs.wallarm.com/installation/cloud-platforms/aws/ami.md)/[GCP](https://docs.wallarm.com/installation/cloud-platforms/gcp/machine-image.md) images: * The NGINX directive `wallarm_tarantool_upstream`, which defines the postanalytics module server address when deployed separately from other NGINX services, has been renamed to [`wallarm_wstore_upstream`](https://docs.wallarm.com/admin-en/configure-parameters-en.md#wallarm_wstore_upstream). Backward compatibility preserved with a deprecation warning: ``` 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 ``` * [Log file](https://docs.wallarm.com/admin-en/configure-logging.md) renamed: `/opt/wallarm/var/log/wallarm/tarantool-out.log` → `/opt/wallarm/var/log/wallarm/wstore-out.log`. * The new wstore configuration file `/opt/wallarm/wstore/wstore.yaml` replaces obsolete Tarantool configuration files such as `/etc/default/wallarm-tarantool` or `/etc/sysconfig/wallarm-tarantool`. * The `tarantool` section in `/opt/wallarm/etc/wallarm/node.yaml` is now `wstore`. Backward compatibility preserved with a deprecation warning. * [Docker image](https://docs.wallarm.com/admin-en/installation-docker-en.md): * All the above changes are applied within the container. * Previously, memory for Tarantool was allocated via the `TARANTOOL_MEMORY_GB` environment variable. Now, memory allocation follows the same principle but uses a new variable: `TARANTOOL_MEMORY_GB` → `SLAB_ALLOC_ARENA`. * Adjusted the container's directory structure to align with Alpine Linux conventions. Specifically: * Content from `/etc/nginx/modules-available` and `/etc/nginx/modules-enabled` has been moved to `/etc/nginx/modules`. * Content from `/etc/nginx/sites-available` and `/etc/nginx/sites-enabled` has been moved to `/etc/nginx/http.d`. * The default `allow` value, specifying permitted IP addresses for the `/wallarm-status` service, is now 127.0.0.0/8 instead of 127.0.0.8/8. * [Kubernetes Ingress Controller](https://docs.wallarm.com/admin-en/installation-kubernetes-en.md): * wstore runs as a separate dedicated pod (`ingress-controller-wallarm-wstore-`), replacing the previous Tarantool postanalytics component. * Helm values renamed: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. * [Kubernetes Sidecar Controller](https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/deployment.md): * Helm values renamed: `postanalytics.tarantool.*` → [`postanalytics.wstore.*`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625). * The following Docker images have been removed from the Helm chart for Sidecar deployment: * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) These images have been replaced by the [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) image, which now runs the relevant services. The described changes are incorporated into the Node upgrade instructions provided below. ## Removal of collectd The collectd service, previously installed on all filtering nodes, has been removed along with its related plugins. Metrics are now collected and sent using Wallarm's built-in mechanisms, reducing dependencies on external tools. Use the [`/wallarm-status` endpoint](https://docs.wallarm.com/admin-en/configure-statistics-service.md), which replaces collectd by providing the same metrics in Prometheus and JSON formats. As a result of this change, also the following changed in the configuration rules: * The `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` collectd configuration file is no longer used. * If you previously used collectd to forward metrics via a network plugin, such as: ``` LoadPlugin network Server "" "" ``` you should now switch to scraping `/wallarm-status` via Prometheus. ## New API Discovery Wallarm's New [API Discovery](https://docs.wallarm.com/api-discovery/overview.md) is now **multi-protocol**: the REST protocol is extended with the support of GraphQL and SOAP. Also, improved user interface and performance make work with the API Discovery more comfortable and effective than before. ### MCP protocol support !!! tip "" MCP discovery requires [NGINX Node 6.12.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) or [Native Node 0.25.0 and higher](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md). [API Discovery](https://docs.wallarm.com/api-discovery/overview.md) now detects [Model Context Protocol](https://modelcontextprotocol.io/) (MCP) servers — the protocol AI agents use to interact with external tools and data sources. MCP discovery is enabled by default and requires no additional configuration. Wallarm discovers MCP server endpoints and their primitives (**tools**, **resources**, **prompts**), displayed in a dedicated **MCP Servers** tab. Discovered servers get auto-created [MCP Session Configurations](https://docs.wallarm.com/api-sessions/mcp-sessions.md#mcp-session-configuration), and MCP traffic is grouped into [MCP Sessions](https://docs.wallarm.com/api-sessions/mcp-sessions.md). Three new [MCP mitigation controls](https://docs.wallarm.com/agentic-ai/mcp-mitigation-controls.md) protect MCP servers: * **ACL policy** — controls access to MCP methods and primitives by user, role, IP, or country * **Request verification** — validates that request parameters (headers, JWT claims) contain expected values * **Tool input schema enforcement** — validates `tools/call` arguments against the schema learned from the server ### GraphQL protocol support !!! tip "" [NGINX Node 6.1.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) and not supported by Native Node so far If some of your APIs utilize the GraphQL protocol and are requested in the real traffic, API Discovery will now detect them. In the built API inventory, you will see data about: * GraphQL operations (queries, mutations, subscriptions) * GraphQL schema Within each GraphQL operation, you will find its details, including transferred sensitive data, risk score and what contributes to it, schema, parameters and headers of requests and responses: ![API Discovery - GraphQL operation details](https://docs.wallarm.com/images/about-wallarm-waf/api-discovery-2.0/api-discovery-endpoint-details-GQL.png) Each request/response parameter information includes: * Parameter name and the part of request/response this parameter belongs to * Path: the hierarchical location of a parameter within a GraphQL query structure * Information about parameter changes (new, unused) * Presence and type of sensitive data transmitted by this parameter, including: * Date and time when parameter value was last transferred by requests ### SOAP protocol support !!! tip "" SOAP protocol discovery requires [NGINX Node](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) 6.2.0+ or Native Node 0.15.1+. If some of your APIs utilize the SOAP protocol and are requested in the real traffic, API Discovery will now detect them. In the built API inventory, you will see data about SOAP operations, including such data as transferred sensitive data, risk score and what contributes to it, XML body parameters, HTTPS and XML headers of requests and responses: ![API Discovery - SOAP operation details](https://docs.wallarm.com/images/about-wallarm-waf/api-discovery-2.0/api-discovery-endpoint-details-SOAP.png) Each request/response XML parameter information includes: * Parameter name (**Key**) * Path: the hierarchical location of a parameter within an XML structure * Parameter type * Namespaces for path elements (from more general to more specific) * Presence and type of sensitive data transmitted by this parameter * Information about parameter changes (new, unused) * Date and time when parameter value was last transferred by requests ### Authentication flow detection !!! tip "" [NGINX Node 6.10.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) and [Native Node 0.23.0 and higher](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md) API Discovery now automatically detects [authentication flows](https://docs.wallarm.com/api-discovery/authentication.md) used by each endpoint. This helps you identify endpoints that lack proper authentication — the #1 API security risk according to OWASP. The module recognizes multiple authentication types including API key, Basic, Bearer, Cookie-based, Digest, AWS Signature v4, Hawk, HMAC signature, Negotiate, NTLM, and SCRAM. For each detected authentication parameter, Wallarm provides coverage percentage based on the last 7 days of traffic. Endpoints are assigned an overall authentication status: **Consistent** (95%+ requests authenticated), **Partial** (0–95%), or **Missing** (0%). Use the **Authentication** filter in the API Discovery inventory to quickly find unauthenticated endpoints. ![API Inventory: Auth flow filter](https://docs.wallarm.com/images/about-wallarm-waf/api-discovery-2.0/api-discovery-auth-flow-filter.png) ## Mitigation Controls We introduce a unified management center for all Wallarm attack mitigation settings - [**Mitigation Controls**](https://docs.wallarm.com/about-wallarm/mitigation-controls-overview.md). With mitigation controls you can: * View and manage all Wallarm mitigation settings in one place. * Manage all in a unified way (all controls have similar configuration UI and options). * Easily overview the current mode of each control: is it active? is it just monitoring or also blocking? * Get quick overview of attacks caught by each control. ![Mitigation Controls page in UI](https://docs.wallarm.com/images/user-guides/mitigation-controls/mc-main-page.png) ### Enumeration attack protection !!! tip "" [NGINX Node 6.1.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) and [Native Node 0.14.1 and higher](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md) New level of protection from [enumeration attacks](https://docs.wallarm.com/attacks-vulns-list.md#enumeration-attacks) comes with enumeration mitigation controls: * [Enumeration attack protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md) * [BOLA enumeration protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md) * [Forced browsing protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md) * [Brute force protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md) Comparing to triggers that were used for this protection before, mitigation controls: * Allow selecting which parameters will be monitored for enumeration attempts. * Allow advanced sophisticated filtering of which exact requests will be counted. * Provide deep integration with [API Sessions](https://docs.wallarm.com/api-sessions/overview.md): the detected attacks are displayed within a corresponding session, providing you with full context of what was happening and why the session activities were marked as attack and blocked. ![BOLA protection mitigation control - example](https://docs.wallarm.com/images/user-guides/mitigation-controls/mc-bola-example-01.png) ### DoS protection !!! tip "" [NGINX Node 6.1.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) and [Native Node 0.14.1 and higher](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md) The [unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) is included in the [OWASP API Top 10 2023](https://docs.wallarm.com/user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) list of most serious API security risks. Being a threat by itself (service slow-down or complete down by overload), this also serves as foundation to different attack types, for example, enumeration attacks. Allowing too many requests per time is one of the main causes of these risks. Wallarm provides the new [**DoS protection**](https://docs.wallarm.com/api-protection/dos-protection.md) mitigation control to help prevent excessive traffic to your API. ![DoS protection - JWT example](https://docs.wallarm.com/images/api-protection/mitigation-controls-dos-protection-jwt.png) ### GraphQL API Protection !!! tip "" [NGINX Node 6.2.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) and [Native Node 0.15.1 and higher](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md) [GraphQL API Protection](https://docs.wallarm.com/api-protection/graphql-rule.md) can now be configured with the dedicated mitigation control (previously, only rules were accessible). ### Default controls Wallarm provides a set of [default mitigation controls](https://docs.wallarm.com/about-wallarm/mitigation-controls-overview.md#default-controls) that, when enabled, significantly enhance the detection capabilities of the Wallarm platform. These controls are pre-configured to offer robust protection against a variety of common attack patterns. The current default mitigation controls include: * [GraphQL protection](https://docs.wallarm.com/api-protection/graphql-rule.md) * [BOLA (Broken Object Level Authorization) enumeration protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md#bola) for user IDs, object IDs, and filenames * [Brute force protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md#brute-force) for passwords, OTPs, and authentication codes * [Forced browsing protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md#forced-browsing) (404 probing) * [Enumeration attack protection](https://docs.wallarm.com/api-protection/enumeration-attack-protection.md#generic-enumeration), including: * User/email enumeration * SSRF (Server-Side Request Forgery) enumeration * User-agent rotation ## File upload restriction policy Wallarm now provides tools for direct restricting the size of uploaded files. This comes as a part of set of measures aimed to prevent the [unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) included in the [OWASP API Top 10 2023](https://docs.wallarm.com/user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) list of most serious API security risks. Depending on your subscription plan, upload restrictions are applied via mitigation control or rule. You can set file size restrictions for the full request or its selected point. !!! tip "" Mitigation-control based protection requires [NGINX Node 6.3.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) or [Native Node 0.16.0 and higher](https://docs.wallarm.com/updating-migrating/native-node/node-artifact-versions.md) ![File upload restriction MC - example](https://docs.wallarm.com/images/api-protection/mitigation-controls-file-upload-1.png) ## Protection from unrestricted resource consumption !!! tip "" [NGINX Node 6.3.0 and higher](https://docs.wallarm.com/updating-migrating/node-artifact-versions.md) and [Native Node 0.16.0 and higher](https://docs.wallarm.com/installation/nginx-native-node-internals.md#native-node). Wallarm's [API Abuse Prevention](https://docs.wallarm.com/api-abuse-prevention/overview.md) introduces the possibility to prevent the [unrestricted resource consumption](https://docs.wallarm.com/attacks-vulns-list.md#unrestricted-resource-consumption) - abusive behavior where an automated client consumes excessive API or application resources without proper limits. This may include sending high volumes of non-malicious requests, exhausting compute, memory, or bandwidth, and causing service degradation for legitimate users. ![API Abuse prevention profile](https://docs.wallarm.com/images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) To detect this type of automated threats, API Abuse Prevention provides a set of three new [detectors](https://docs.wallarm.com/api-abuse-prevention/overview.md#how-api-abuse-prevention-works): * **Response time anomaly** identifying abnormal patterns in the latency of API responses that may signal automated abuse or backend exploitation attempts. * **Excessive request consumption** identifying clients that send abnormally large request payloads to the API, potentially indicating abuse or misuse of backend processing resources. * **Excessive response consumption** flagging suspicious sessions based on the total volume of response data transferred over their lifetime. Unlike detectors focused on individual requests, this detector aggregates response sizes across an entire session to identify slow-drip or distributed scraping attacks. ## Blocking by session !!! tip "" API session blocking requires [NGINX Node](https://docs.wallarm.com/installation/nginx-native-node-internals.md#nginx-node) 6.5.1+ or [Native Node](https://docs.wallarm.com/installation/nginx-native-node-internals.md#native-node) 0.19.0+. Wallarm now provides a new protection action - [blocking by session](https://docs.wallarm.com/api-sessions/blocking.md#blocking-sessions). It allows for more intelligent security decisions based on the state of the current interaction with the application, rather than just its network origins ([source IP addresses](https://docs.wallarm.com/user-guides/ip-lists/overview.md)). Blocking by session is required for the cases of: * Dynamic source IP addresses * Attackers switching IP addresses via proxy servers, VPNs or other means * Bot attacks, utilizing a number of machines with diverse IP addresses * Invalidating the specific stolen session (directly stops the hijack) * Necessity of immediate revocation of current access for actively logged in session The session can be blocked automatically by: * [Mitigation control](https://docs.wallarm.com/about-wallarm/mitigation-controls-overview.md) ![!Mitigation control - blocking by session](https://docs.wallarm.com/images/api-sessions/api-sessions-blocking-mc.png) * Wallarm's [API Abuse Prevention](https://docs.wallarm.com/api-abuse-prevention/overview.md) ![!API Abuse Prevention profile - blocking by session](https://docs.wallarm.com/images/api-sessions/api-sessions-blocking-api-abuse.png) You can also block/unblock any session manually at any moment. ## Security Issues: all vulnerabilities in one unified view As for now, Wallarm offers multiple [methods](https://docs.wallarm.com/about-wallarm/detecting-vulnerabilities.md#detection-methods) of detecting vulnerabilities (security issues) which vary at scope, usage scenarios, required elements (with or without node) and a set of vulnerabilities they are able to find. Previously vulnerabilities found by different methods were displayed in different sections of Wallarm Console - now the view is unified and you can see all of them in one place - the **Security Issues** section. ![Security Issues](https://docs.wallarm.com/images/api-attack-surface/security-issues.png) Here you can: * Easily view and [manage](https://docs.wallarm.com/user-guides/vulnerabilities.md) the list of found vulnerabilities distinguished by the risk level * Access detailed information on each security issue (vulnerability): description, mitigation measures, links to relates CWEs, history of status changes and comments from your team members * Close and re-open vulnerabilities * Get reports The old **Vulnerabilities** section is not displayed anymore. ## OAS 3.1 support !!! tip "" OAS 3.1 support in [API Specification Enforcement](https://docs.wallarm.com/api-specification-enforcement/overview.md) requires [NGINX Node](https://docs.wallarm.com/installation/nginx-native-node-internals.md#nginx-node) 6.6.1+ or [Native Node](https://docs.wallarm.com/installation/nginx-native-node-internals.md#native-node) 0.20.0+. For [API Specification Enforcement](https://docs.wallarm.com/api-specification-enforcement/overview.md), you can now upload OpenAPI specifications of **version 3.1**. ## Which Wallarm nodes are recommended to be upgraded? * Client and multi-tenant Wallarm NGINX Nodes of version 4.10 and 5.x to stay up to date with Wallarm releases and prevent [installed module deprecation](https://docs.wallarm.com/updating-migrating/versioning-policy.md#version-support-policy). * Client and multi-tenant Wallarm nodes of the [unsupported](https://docs.wallarm.com/updating-migrating/versioning-policy.md#version-list) versions (4.8 and lower). If upgrading from the version 3.6 or lower, learn all changes from the [separate list](https://docs.wallarm.com/updating-migrating/older-versions/what-is-new.md). ## Upgrade process 1. Review [recommendations for the module upgrade](https://docs.wallarm.com/updating-migrating/general-recommendations.md). 2. Upgrade installed modules following the instructions for your Wallarm node deployment option: * NGINX Node: * [DEB/RPM packages](https://docs.wallarm.com/updating-migrating/nginx-modules.md) * [All-in-one installer](https://docs.wallarm.com/updating-migrating/all-in-one.md) * [Docker container with the modules for NGINX](https://docs.wallarm.com/updating-migrating/docker-container.md) * [NGINX Ingress controller with integrated Wallarm modules](https://docs.wallarm.com/updating-migrating/ingress-controller.md) * [Sidecar controller](https://docs.wallarm.com/updating-migrating/sidecar-proxy.md) * [Cloud node image](https://docs.wallarm.com/updating-migrating/cloud-image.md) * [Multi-tenant node](https://docs.wallarm.com/updating-migrating/multi-tenant.md) * Native Node: * [All-in-one installer](https://docs.wallarm.com/updating-migrating/native-node/all-in-one.md) * [Helm chart](https://docs.wallarm.com/updating-migrating/native-node/helm-chart.md) * [Docker image](https://docs.wallarm.com/updating-migrating/native-node/docker-image.md) ---------- [Other updates in Wallarm products and components →](https://changelog.wallarm.com/)