chore: release 3.18.0

[shreemaan-abhishek]

Description

Release 3.18.0.

This PR:

• Adds the 3.18.0 section to CHANGELOG.md (and its Table of Contents entry), covering all PRs merged to master since the release/3.17 branch was cut. Backward-incompatible changes are grouped under Change and marked with ⚠️.
• Bumps the version to 3.18.0 in apisix/core/version.lua and docs/{en,zh}/latest/config.json.
• Extends ci/check_changelog_prs.ts IGNORE_PRS with changes that are not user-facing: test-only, CI-only and build-only work whose subject prefix (fix:, fix(ci), fix(dev-image), build:) dodges the docs/chore/test/ci type filter (fix(ci): verify LuaRocks tarball checksum before install #13526, fix: reduce vulnerable test dependencies #13554, fix: remove dead chaos tests and bump vulnerable test dependencies #13679, fix(ci): wait for the kafka broker before creating topics #13709, fix(dev-image): add libwww-perl #13815, build: depend on a rapidjson rock that is not tied to the build host CPU #13824).
• Bumps APISIX_DASHBOARD_COMMIT in .requirements to 045e314 (current apisix-dashboard master). APISIX_RUNTIME is already at 1.3.16 on master, so it is unchanged.

Breaking changes (see the Change section)

• change(debug): report executed plugins with phase in execution order #13710 change(debug): report executed plugins with phase in execution order
• feat: bound request and response body buffering in plugins #13705 feat: bound request and response body buffering in plugins
• fix(batch-processor): bound the pending entries backlog by default #13826 fix(batch-processor): bound the pending entries backlog by default
• refactor(ai-aws-content-moderation): moderate decoded LLM content in access phase #13647 refactor(ai-aws-content-moderation): moderate decoded LLM content in the access phase
• feat(ai-aliyun-content-moderation): role-aware request_check_mode and O(n) content chunking #13598 feat(ai-aliyun-content-moderation): role-aware request_check_mode and O(n) content chunking
• fix(sls-logger): verify the TLS certificate of the log server #13785 fix(sls-logger): verify the TLS certificate of the log server
• fix(openid-connect): enforce audience, issuer and required scopes #13829 fix(openid-connect): enforce audience, issuer and required scopes
• fix(admin): duplicate consumer authentication keys are silently accepted #13529 fix(admin): reject duplicate consumer authentication keys instead of silently accepting them
• perf(core): sanitize the X-Forwarded-* headers in the NGINX config #13803 perf(core): sanitize the X-Forwarded-* headers in the NGINX config

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change (N/A: release bookkeeping only, no runtime code changes)
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (this PR itself only touches release metadata; the breaking changes it documents landed in their own PRs and are listed in the Change section)

[kayx23]

PR #13803 does not remove all three variables. Its merged NGINX template still defines $var_x_forwarded_host and $var_x_forwarded_port as map outputs; they are no longer writable from Lua. Only $var_x_forwarded_proto is removed. Please change this to something like: “$var_x_forwarded_proto is removed, while $var_x_forwarded_host and $var_x_forwarded_port are no longer writable.”

[shreemaan-abhishek]

Good catch, fixed in 9bce154 with your wording. Verified: ngx_tpl.lua still defines $var_x_forwarded_host and $var_x_forwarded_port as map outputs and feeds them to the more_set_input_headers directives; only $var_x_forwarded_proto is gone, replaced by $scheme. All three did leave the Lua-writable list in core/ctx.lua, which is what the entry now says.

[kayx23]

This should be marked as backward-incompatible and moved to Change. PR #13778 changes the default from lua-resty-http to ngx_http_ffi_client; on a hand-built or older runtime without the module, AI requests now fail deliberately instead of falling back. Such deployments must set plugin_attr.ai-proxy.http_client: lua-resty-http to preserve the previous behavior.

[shreemaan-abhishek]

APISIX v3.18.0 should be installed along with the new runtime which will guarantee no breaking change. We do not guarantee back-compat with a new APISIX version running on an older runtime.

[shreemaan-abhishek]

Keeping this one in Core, for the reason above. Every release repins APISIX_RUNTIME in .requirements (1.3.11 -> 1.3.16 this cycle), so "requires this release's runtime" would make most runtime-dependent work backward-incompatible and dilute the Change section. I have reworded the entry in 9bce154 to say the client ships with the runtime pinned by this release, and to name the plugin_attr.ai-proxy.http_client: lua-resty-http opt-out for hand-built runtimes without the module.

[kayx23]

This should be marked as backward-incompatible and moved to Change. PR #13601 introduces a default 64 MiB cap for JSON/multipart post_arg.* matching. A request above that size previously could match the route; after this change the predicate resolves to nil and the route returns 404. Operators must raise apisix.max_post_args_readable_size or set it to 0 to preserve the old unlimited behavior.

[shreemaan-abhishek]

you are right. although we allow backcompat behaviour, request paths with body larger than 64 mb will no longer work. this is something upgraders should be aware of.

[shreemaan-abhishek]

Agreed, moved to Change with ⚠️ in 9bce154, including the migration action (raise the value, or set it to 0). Worth adding that this is reachable in a default install rather than only on tuned deployments: client_max_body_size defaults to 0 (unlimited), so a body above 64 MiB does reach route matching.

[kayx23]

PR #13762 also introduces a backward-incompatible change for the existing ldap-auth plugin: the lua-resty-ldap upgrade makes tls_verify: true perform real certificate verification, whereas it was previously a silent no-op. Deployments using self-signed or hostname-mismatched LDAP certificates may start failing. Please add this impact under Change (with the migration action: install a trusted/matching certificate or explicitly disable verification where appropriate), while keeping the new ldap-auth-advanced plugin here as a feature.

[shreemaan-abhishek]

Confirmed, and added as its own Change entry in 9bce154 while keeping the new plugin under Plugins. The mechanism: in lua-resty-ldap 0.1.0 the handshake read conf.verify_ldap_host (init.lua:78) while ldap-auth passes tls_verify, so the argument was always nil and sslhandshake(true, host, nil) verified nothing. 0.3.1 maps ssl_verify = conf.tls_verify, so the flag now takes effect. Scope is limited to deployments that explicitly set tls_verify: true, which are exactly the ones that believed verification was already on.

[kayx23]

This is not only a refactor. PR #13699 fixes a credential-leak path: ai-request-rewrite internal LLM calls previously forwarded the downstream client’s Authorization and Cookie headers to the configured third-party LLM endpoint. The new ctx-free/internal-call split stops that forwarding and uses only the plugin’s configured credentials. Please categorize this as a fix and describe the user/security impact.

[shreemaan-abhishek]

Agreed, recategorised as fix(ai-request-rewrite) in 9bce154 with the user impact described. One refinement to the wording: the pre-image copied every client header and then merged ext_opts_headers over them, so when the provider authenticates through the Authorization header the client's value was overwritten. Cookie and any other client headers (custom API keys, session tokens) leaked unconditionally, and Authorization leaked whenever the provider uses query-param, api-key or SigV4 auth. The entry is phrased to match that.

[kayx23]

This entry should also describe the correctness fix and use fix(loggly): the old module-level handle_http_payload closure was overwritten by whichever route logged last, so asynchronous batches from two routes could be sent with the wrong route’s token/tags/config. PR #13648 adds a two-route regression test for that behavior; reducing per-request allocations is an additional performance benefit.

[shreemaan-abhishek]

Agreed, it is fix(loggly) now in 9bce154. Confirmed the mechanism: handle_http_payload was a module-level local assigned inside _M.log on every request, while handle_log resolved it at flush time, so a batch queued for one route could be sent with another route's token, tags and endpoint. The reduced per-request allocation is described as the secondary benefit.

[kayx23]

This should be marked backward-incompatible under Change. PR #13805 states that a Consumer whose user_dn was written in the previous unescaped form will stop matching when the LDAP username contains RFC 4514 structural characters (for example comma,user). Operators must update those Consumer user_dn values to the escaped bind-DN form, such as cn=comma\\,user,....

[shreemaan-abhishek]

Agreed, moved to Change in 9bce154 with the escaped-DN migration example. Scope note for upgraders: only usernames containing RFC 4514 structural characters change key, since the library escapes the RDN value and returns the canonical bind DN that the plugin now keys the consumer lookup on.

[kayx23]

This should be marked backward-incompatible under Change. PR #13487 changes the existing apisix_llm_latency metric schema by adding a type label, and streaming requests now emit both type="total" and type="ttft" samples. The PR explicitly tells operators to update existing queries with type="total"; dashboards, alerts, and recording rules need that migration.

[shreemaan-abhishek]

Agreed, moved to Change in 9bce154. Confirmed against the 3.17.0 tag: llm_latency was defined there with no type label, and this PR prepends it and emits both type="total" and type="ttft" for streaming requests, so existing dashboards and alerts double-count until they select type="total". The entry now carries that migration.

[kayx23]

This should be marked backward-incompatible under Change. fail_mode is additive, but its default skip intentionally changes existing behavior for unrecognized/non-AI traffic: ai-aliyun-content-moderation changes from 500 to pass-through, and ai-aws-content-moderation changes from moderating the raw body to pass-through. Operators that require fail-closed handling must set fail_mode: error.

[shreemaan-abhishek]

Agreed, moved to Change in 9bce154. Confirmed the direction of the change: ai-aliyun-content-moderation previously returned 500 for a missing AI instance and an unsupported protocol, and 400 for an unsupported content-type; all three now go through binding.on_unsupported with the skip default and pass the request through unmoderated. The entry names fail_mode: error as the way to keep the previous fail-closed behaviour.

[shreemaan-abhishek]

Thanks for the review @kayx23. Eight of the nine are addressed in 9bce154; the ngx_http_ffi_client one stays in Core for the runtime-pinning reason discussed in that thread, with sharper wording.

The Change section goes from 9 to 14 entries:

• moved in: feat: add max_post_args_readable_size to bound post_arg.* body reads #13601, fix(ldap-auth): key the consumer lookup on the escaped bind DN #13805, feat(prometheus): add built-in LLM histograms for TTFT and token distribution #13487, feat(ai-plugins): add fail_mode for Consumer-bound protocol handling #13489
• added: the ldap-auth tls_verify impact carried by feat: add ldap-auth-advanced plugin (core authentication) #13762 (the plugin itself stays under Plugins)
• reworded: perf(core): sanitize the X-Forwarded-* headers in the NGINX config #13803

Recategorised in Plugins: #13699 refactor -> fix(ai-request-rewrite) and #13648 perf -> fix(loggly), both with the user-visible impact spelled out.

Section totals are now Change 14 / Core 52 / Plugins 99, 165 entries. check_changelog_prs and markdownlint both still pass locally.

The Chinese counterpart in #13843 has been updated in lockstep, so the two files stay line-for-line equivalent.

[kayx23]

One remaining correction: this still generalizes the previous hard-error/fail-closed behavior to AWS. PR #13489 states that Aliyun returned 500/400, while AWS moderated the raw body (and ai-prompt-guard already passed through). Please use wording such as: “The skip default changes unrecognized or non-AI traffic to pass-through: Aliyun no longer returns an error, and AWS no longer moderates the raw body. Set fail_mode: error where unrecognized traffic must be rejected.”

[shreemaan-abhishek]

Good catch, applied in a02cb7e. Verified the AWS pre-image: _M.rewrite read the body with core.request.get_body() and moderated it, with no content-type or protocol gate at all, so the gate added here is what turns non-JSON traffic into a skip. Calling that a "hard error" was wrong, and it hid the part that actually matters for upgraders: traffic that used to be scanned silently stops being scanned.

I extended your wording slightly to cover the third plugin. ai-prompt-guard was not purely pass-through before either: a body that failed JSON parsing returned 400, which now becomes pass-through at the skip default. Its other path, a body matching no AI protocol, was silently allowed before and still is, so nothing changes there.

The entry now reads:

Its skip default lets unrecognized or non-AI traffic through instead of failing: ai-aliyun-content-moderation and ai-prompt-guard no longer return an error, and ai-aws-content-moderation no longer moderates a non-JSON body as raw text. Set fail_mode: error where such traffic must be rejected.

The Chinese counterpart in #13843 carries the same change.