One conflict, in yarn.lock: hono's resolved version. develop had drifted
to 4.13.9, next carries 4.13.13 from #10569. Both clear CVE-2026-93981
(fixed in 4.13.7); took next's so the branches stay aligned. The entry
header is identical on both sides (hono@^4.11.4), only the resolution
differed.
The lockfile was merged as text; yarn install was deliberately not
re-run, for the reason recorded in the previous merge.
Validated: 4617 blocks, 6020 patterns, 10263 dependency refs, 0
unresolvable, 0 duplicates.
Closes 8 of the 18 findings in the 2026-10-05 scan.
nodemailer ^9.1.1 -> ~10.0.9 (resolves 10.0.14). Six advisories, three
of them high: GHSA-prgh-xp8r-p3m5, GHSA-v53p-9fqp-m79j (quadratic
backtracking in the addressparser free-text fallback),
GHSA-6vj9-mwq6-2f5v, GHSA-8vvx-rff5-p5rq, GHSA-g57g-f23g-4646 (quoted
local-part producing a malformed envelope recipient, patched in 10.0.9).
Every advisory range is of the form `>= 9.1.0, < 10.0.x`, so 9.x has no
backport and the major bump is the only route. 10.0.9 is the lowest
release covering all six.
Pinned with `~` rather than `^` to stay within 10.0.x. Not pinned
exactly at 10.0.9, because the patches after it are ones we want:
10.0.11 restores the CommonJS entry point and the @types/nodemailer
declaration layout, and 10.0.12 settles every send on a connection
error and backs off pool requeues -- this code uses `pool: true`.
10.0.0 carries one breaking change, "Node.js 20 or newer is required".
This repo requires node >= 22 and builds on node:22-bookworm, so it does
not apply. The v7/v8/v9 breaking changes listed in the changelog are
already in effect at 9.1.1. 10.0.0 also explicitly keeps a transporter
assignable to the plain Transporter type, which is how the three call
sites use it; verified by type-checking the exact usage (createTransport
with a pool config, Map<string, Transporter>, sendMail, close) against
both 10.0.9 and 10.0.14, and by loading it at runtime.
hono and moment needed no manifest change: their existing ranges
(^4.11.4, ^2.29.1/^2.30.1) already admit the patched releases, the
lockfile was just pinned to stale resolutions. Refreshing them moves
hono 4.13.5 -> 4.13.13 (CVE-2026-93981, hono/jsx XSS before 4.13.7) and
moment 2.29.4/2.30.1 -> 2.31.0 (CVE-2026-17495, path traversal via a
crafted non-string locale). The two moment entries now resolve to the
same version and are merged.
The lockfile was edited as text rather than regenerated: pro-plugins is
not part of this repository but participates in workspace resolution, so
a plain yarn install drops entries it owns. Validated at 4615 blocks,
6018 patterns, 10262 dependency refs, 0 unresolvable, 0 duplicates, no
out-of-order entries, and verified by installing against it.
Not addressed, no upstream fix exists:
- braces 3.0.3 (GHSA-vfj7-8cjw-p6xm) -- latest is 3.0.3 and the advisory
records no patched version; reached only via micromatch/chokidar.
- basic-ftp 5.3.1 (CVE-2026-102990) -- get-uri 8.0.1, the latest, still
depends on basic-ftp ^5.3.1; reached via pm2 -> proxy-agent ->
pac-proxy-agent -> get-uri, and the parser is only exercised by
Client.list() against an FTP server.
- mariadb 2.5.6 -- connector v3 is incompatible with sequelize 6.
* fix(client-v2): keep empty cardless JS blocks accessible in the UI editor
* refactor(client-v2): pass JS block editor min height as a prop
The model's reactive render wrapper already re-renders on UI editor
toggles, so the extra observer wrapper is unnecessary. Use the theme's
controlHeightLG token instead of a hard-coded value.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
One conflict, in yarn.lock: form-data's entry. develop had
`^4.0.0, ^4.0.6`, next had `^4.0.0, ^4.0.5, ^4.0.6`. Took next's, which
is the union -- both resolve to the same 4.0.6, and ^4.0.5 is required
by a package on main.
Also dropped the orphaned @nocobase/utils@3.0.0-alpha.4 entry. It was
already dangling on develop before this merge: it declares a dependency
on @budibase/handlebars-helpers@0.14.0, which no longer has a block
(develop only carries 0.14.3), while nothing in the tree requires
@nocobase/utils@3.0.0-alpha.4 itself -- zero consumers inside the
lockfile and no workspace package.json declares it. Removing it takes
the lockfile from 1 unresolvable reference to 0.
The lockfile was merged as text; yarn install was deliberately not
re-run. Re-running it during conflict resolution is what re-resolved the
whole file on 2026-09-24 in f9f77620be, drifting 42 packages and pulling
axios to a version whose type signature broke the sdk build.
Validated: 4625 blocks, 6034 patterns, 10288 dependency refs, 0
unresolvable, 0 duplicates.
* fix(deps): upgrade axios to 1.20.0
main resolves axios@^1.7.0 to 1.7.7 and axios@^1.7.8 to 1.7.9, which
carry 30 known advisories between them -- SSRF, credential leakage,
prototype pollution and DoS -- and has done so for over two months.
^1.7.0 is the entry the nine workspaces declare, so it is what
@nocobase/sdk and every APIClient request actually run on.
develop meanwhile fails its declaration build:
APIClient.ts:175 - error TS2322: Type 'Promise<AxiosResponseResult<T, R, D, any>>'
is not assignable to type 'Promise<R>'
Both have one cause. develop drifted to axios 1.20.0 on 2026-09-24 in
f9f77620be, a next -> develop sync where yarn install was re-run to
resolve a lockfile conflict, re-resolving the whole file to whatever was
latest on npm. 1.20.0 carries no advisories, so the drift accidentally
fixed the security problem, but axios 1.19.0 had changed request() from
three generics returning Promise<R> to four returning
Promise<AxiosResponseResult<T, R, D, P>>, and the declared type stopped
matching.
Fixing it here and letting it flow main -> next -> develop closes the
advisories on the release branch, the type build on develop, and the
divergence between them.
Merge the four 1.x ranges into one entry at 1.20.0. form-data@^4.0.6
joins the existing ^4.0.0/^4.0.5 entry, which already resolves to 4.0.6.
axios@^0.18.1 is untouched; 0.x cannot merge into a 1.x entry.
APIClient gets one assertion. AxiosResponseResult<T, R, D, P> is a
conditional type that is R whenever R is not the default, but TypeScript
cannot prove that for an unbound generic. The assertion is accurate,
emits no runtime code and is not `as any`. Widening request()'s own
signature to mirror axios would leak axios internals into the public SDK
surface and affect every caller, so it is not done.
axios 1.8.0 is the only release in this range flagged BREAKING, for
allowAbsoluteUrls, and it does not reach us. The default when unset is
true (lib/core/Axios.js), which makes buildFullPath's second clause
always false and reduces it to 1.7.7's exact condition. The flag does
not appear anywhere in this repository. server-request.ts, the
SSRF-guarding wrapper, is unaffected for three independent reasons: it
passes no baseURL so the first clause short-circuits in both versions,
its whitelist check reads config.url before any combination, and
redirects are validated per hop via beforeRedirect, which never reaches
buildFullPath.
The lockfile was edited as text rather than regenerated: pro-plugins is
not in this repository but participates in workspace resolution, so a
plain yarn install drops entries it owns -- one here deleted
axios@^1.4.0, which dingtalk-stream needs. Validated at 4619 blocks,
6022 patterns, 10277 dependency refs, 0 unresolvable, 0 duplicates, and
verified by installing against it (axios resolves to 1.20.0) and by
type-checking APIClient.ts, which passes with the assertion and
reproduces the exact CI error without it.
* fix(plugin-file-manager): narrow content-type header to string
axios 1.20.0 widened the type of lowercase response header keys. In
1.7.7 only the capitalised forms were listed:
type CommonResponseHeadersList = 'Server' | 'Content-Type' | ...
so headers['content-type'] fell through to the RawAxiosHeaders index
signature and inferred string. 1.20.0 adds the lowercase forms:
type CommonResponseHeaderKey = CommonResponseHeadersList | Lowercase<CommonResponseHeadersList>
so it now infers AxiosHeaderValue, which includes number and cannot be
assigned to contentType?: string.
This file did not fail the repo's own build because that build does not
reach it, but the same pattern breaks plugin-action-export-pro in the
pro-plugins build. Reproduced locally against axios 1.20.0.
* fix(client-v2): show popup parent record variable in quick create popups of unsaved forms
When a record select field opens its quick create popup from a form whose
record has no primary key yet (e.g. the approver's interface configured in
the workflow canvas), neither associationName nor sourceId was passed, so the
"Current popup parent record" variable was hidden and could not be configured.
Pass a meta-only sourceAssociationName in that case and let createPopupMeta
build the parent record meta from it. Runtime resolution still relies on
sourceId, and block resource binding in the popup is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(client-v2): retain popup configuration mode
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* feat(plugin-ai): expose referenced knowledge base documents in chat responses
- retrievePrompt now returns { prompt, documents } with the matched knowledge base documents
- move knowledge base retrieval out of getSystemPrompt into buildChatContext
- stream a new knowledge_base_references event for pre-retrieved and tool-retrieved documents
- persist deduplicated references to the last AI message metadata when the stream ends
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* refactor(plugin-ai): emit pre-retrieved knowledge base references before stream end
Send the pre-retrieved documents right before stream_end with the last AI message id
instead of right after stream_start. Tool-retrieved documents are still emitted in real time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* feat(plugin-ai): include extname in knowledge base references
Let the frontend build the download filename as title + extname,
the same way the knowledge base document list does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* revert(plugin-ai): emit pre-retrieved knowledge base references after stream start
Restore sending the pre-retrieved documents right after stream_start.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* refactor(plugin-ai): drop messageId from tool knowledge base reference events
References are persisted on the last AI message of the turn, which can differ from the
message that issued the tool call, so the tool event no longer carries a messageId.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The scan was run against an image built before #10542 (it reports
pdfjs-dist 5.6.205, which came from the old `^5.3.31`), so pdfjs-dist is
already resolved. js-yaml and uuid were not.
js-yaml (CVE-2026-84375, fixed in 3.15.2 / 4.3.2) needed no new override:
every range in the tree (`^3.13.1`, `^4.1.0`, `^4.1.1`) already admits a
patched version, the lockfile was just pinned to stale resolutions.
Refreshing them moves `^3.13.1` to 3.15.2 and `^4.x` to 4.3.2.
pm2 is the one exception — 7.0.4 still pins js-yaml 4.3.1 exactly. The
root `**/pm2/js-yaml` override already covered this repo, but the image
installs the create-nocobase-app template, whose own `resolutions` did
not carry it, so the fix never reached the published image. Add it there.
uuid (CVE-2026-41907, fixed in 11.1.1 / 12.0.1 / 13.0.1 / 14.x) cannot be
fixed at the source. Refreshing the lockfile moves `^11`, `^13` and `^14`
to patched releases, but `^8`, `^9` and `^10` are capped below every fix
and the upstreams have no path forward — sequelize 6.37.8, exceljs 4.4.0
and koa-proxies 0.12.4 all still depend on uuid `^8`/`^9`. Pin `**/uuid`
to 11.1.1: it is patched, it is the last line shipping a CommonJS build,
and it satisfies `^8` through `^11` consumers. uuid's breaking changes
between v11 and v14 are environmental (CommonJS removal, global crypto,
dropped Node versions), not API changes, so the langchain packages asking
for `^13`/`^14` keep every symbol they import.
request must stay on uuid 3.x: it does `require('uuid/v4')`, a subpath
the v7+ exports map no longer exposes, so `**/uuid` alone breaks both
request and its dependent cos-nodejs-sdk-v5 with ERR_PACKAGE_PATH_NOT_
EXPORTED, taking Tencent COS storage down with it.
`**/temp-write/uuid` has to accompany it. temp-write itself is fine on
v11 — it calls `uuid.v4()`, which still exists — but it declares the same
`uuid@^3.3.2` spec as request, and a yarn v1 lockfile is keyed by
`name@range`, so one spec cannot resolve to two versions. Dropping the
temp-write entry silently collapses `uuid@^3.3.2` onto 11.1.1 and takes
the request guard with it. The two are only effective as a pair.
Both are dev-only — request comes from cos-nodejs-sdk-v5 and temp-write
from lerna — and a production install of the template contains neither.
Also bump @budibase/handlebars-helpers 0.14.0 -> 0.14.3, which moved to
uuid `^11.1.1` upstream. Its helper set is unchanged (176 helpers, no
additions or removals).
mariadb is left alone: the 2.x line ended at 2.5.6 with no backport, the
advisories are first fixed in 3.2.4, and connector v3 is incompatible
with sequelize 6.
* feat(plugin-ai): inject OpenCode request headers into LLM providers
- Add requestContext (sessionId) to LLM providers, passed from AI employee
conversations, workflow LLM nodes and test flight
- Add LLMProvider.getDefaultHeaders(): returns a custom User-Agent and
x-opencode-session when baseURL targets opencode.ai, otherwise empty
- Merge the default headers into every provider's model client and
model listing requests
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(plugin-ai): pass session context to web search and AI translate requests
- subAgentWebSearch passes the conversation sessionId to the LLM
provider, falling back to a generated id, so OpenCode requests carry
x-opencode-session
- Localization AI translate task uses its task id as the session
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(plugin-ai): align DeepSeek capabilities with V4.1-Flash
- Add supportsImageInput and send image attachments to Flash models
(deepseek-flash, deepseek-v4-flash, deepseek-v4-flash-vision-exp,
deepseek-v4.1-flash); V4-Pro silently drops images
- Disable web search for Flash models: V4.1-Flash ignores the built-in
web_search tool and answers from stale knowledge; keep it for V4-Pro
- Register deepseek-flash as a default model
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
gchust