mirror of
https://github.com/twentyhq/twenty.git
synced 2026-09-22 21:46:17 -04:00
Charles Bochet
8873f793d3
Bumps the packages still flagged by open advisories in the built server image, and moves the `application-package` seed-dependencies fixture off a vulnerable `sharp`. ## Packages | Package | From | To | Advisory | |---|---|---|---| | js-yaml | 4.3.0 | 4.3.1 | GHSA-5p4m-2wfm-xmqj (high) | | sharp | 0.34.5 | 0.35.3 | GHSA-f88m-g3jw-g9cj (high) | | brace-expansion | 2.1.2 / 5.0.8 | 2.1.4 / 5.0.9 | CVE-2026-14257, CVE-2026-69152 (high) | | ip-address | 10.2.0 | 10.4.0 | CVE-2026-69192 (high), CVE-2026-54272 + CVE-2026-69198 (medium) | | dompurify | 3.4.12 | 3.4.13 | GHSA-55q2-fjhq-7xh7 (medium) | They live in three separate dependency graphs that all end up in the image, so a root `yarn up` only covers the first: 1. the root workspace — js-yaml, dompurify 2. `application-package/constants/seed-dependencies/yarn.lock` — sharp, brace-expansion, ip-address 3. `logic-function-drivers/constants/common-layer-dependencies/yarn.lock` — brace-expansion **js-yaml** is quadratic CPU consumption in `resolveYamlOmap()`. `!!omap` is registered in the default schema, so a plain `yaml.load(untrusted)` is affected, and there is no backport below 4.3.1. The seven scoped mintlify/verdaccio pins plus `front-matter` and `@istanbuljs/load-nyc-config` all move together so the shared 4.x lock entry lifts as one — it does, leaving a single `js-yaml@npm:4.3.1, js-yaml@npm:^4.1.0` entry with no 3.x copy resurrected. The `//resolutions` note is updated with the advisory and the new drop condition. **brace-expansion, ip-address, dompurify** are caret-range lifts; no declared range is touched. ## sharp: why the earlier deferral no longer applies sharp is a *direct* dependency of the seed-dependencies fixture, so clearing GHSA-f88m-g3jw-g9cj (four inherited libvips CVEs, fixed in 0.35.0) means moving the declared range. #23333 deliberately left it out on three grounds: **"The same `^0.34.5` ceiling gates twenty-sdk and 15 app manifests"** — no longer true. `twenty-sdk` is already on `^0.35.3`; the only `^0.34.5` left is `packages/twenty-apps/public/call-recorder/package.json`, which is not in the server image. **"Lambda layers are still advertised as NODE18-compatible"** — a real constraint. sharp 0.35 requires Node `>=20.9.0`, and the `@img/sharp-linux-*` prebuilt binaries carry the same floor, so a `nodejs18.x` function could not load it. It is worth being precise about why that is nonetheless safe, because the tempting argument is wrong. Functions are *not* always `nodejs22.x`: the `runtime` column defaulted to `nodejs18.x` from #6388 until #12488, and that migration only ran `ALTER COLUMN "runtime" SET DEFAULT 'nodejs22.x'` without backfilling. `LambdaExecutorManagerService` passes `Runtime: flatLogicFunction.runtime` straight from the row, so pre-#12488 functions can still be `nodejs18.x`. The actual reason is that **an existing function cannot reach the new fixture at all**: - the deps layer is named `deps-<flatApplication.yarnLockChecksum>` (`getLambdaDepsLayerName`), read from the application's own column; - `ensureDepsLayer` returns the existing layer ARN untouched whenever a layer with that name exists; - when it does build one, `getDependencyContents` → `copyDependenciesInMemory` pulls that application's **own** `package.json` and `yarn.lock` from file storage, and writes an empty v1 lockfile if none exists — it never falls back to the fixture. The fixture is read in exactly three places: `createTwentyStandardApplication`, `createWorkspaceCustomApplication`, and `uploadDefaultPackageFilesAndSetFileIds`. That is new-workspace and new-application creation, plus `application:rebuild-default-deps`, which is a plain `@Command` rather than a registered instance or workspace command, so it does not run on deploy. **Blast radius is new workspaces and newly created applications.** Existing applications keep their stored checksum, their own lockfile and their already-published layer; nothing rebuilds, nothing rotates, no function is redeployed. Functions still on `nodejs18.x` are unaffected for the same reason — and they are already undeployable regardless of this PR, since Lambda blocks create and update on that runtime. Worth a separate runtime backfill. **"It changes the package set exposed to user logic functions"** — this one stands, scoped to new workspaces. sharp 0.35.0 has breaking changes user code could notice: `failOnError` removed, `paletteBitDepth` gone from `metadata`, deprecated `sharpen` properties removed, `format.jp2k` renamed to `format.jp2`, a new `limitInputChannels` defaulting to 5, and AVIF quality retuned to SSIMULACRA2-based `iq` metrics. That is the cost of the fix, paid only by workspaces created from here on; the alternative is pinning new workspaces to a known-vulnerable sharp indefinitely. ## Checksum coupling The seed-dependencies fixture is pinned by `DEFAULT_PACKAGE_JSON_CHECKSUM` / `DEFAULT_YARN_LOCK_CHECKSUM`. Verified in order: the hash formula reproduces **both** stored constants against the pre-change content, then both were regenerated. Unlike #23333, `package.json` changes here (sharp), so both constants move. `availablePackages` is unchanged apart from `sharp: 0.34.5 -> 0.35.3` — nothing dropped — and the fixture sits at 341 lock entries against the 1000-entry `MAX_PACKAGE_VERSION_MATCHES` cap. Nothing compares stored against default checksums to gate a rebuild, so no migration is needed. `common-layer-dependencies` has no stored checksum: `getCommonLayerName()` content-hashes its `package.json` + `yarn.lock`, so the lockfile change rotates the layer name on its own. ## Layer size Net package-set change in the fixture is `+@img/sharp-freebsd-wasm32` and `+@img/sharp-webcontainers-wasm32`, optional dependencies for platforms Lambda never resolves. On the linux-x64 path that actually installs, sharp goes from ~16 MiB to ~18 MiB unpacked (core 521 KiB → 936 KiB, libvips 1.2.4 → 1.3.2 at 16.3 → 17.8 MiB). Immaterial against the 250 MB unzipped layer limit and the 4096 MB yarn-install Lambda from #23805. ## Verification - the hash formula reproduces both pre-change constants, and both new constants match the new content - `yarn install --immutable` passes in both fixtures - `yarn constraints` passes - `nx lint:diff-with-main twenty-server` passes - every target version clears the 3-day `npmMinimalAgeGate` (newest is dompurify 3.4.13) ## Not included react-router 6.30.4 (CVE-2026-53666 arbitrary constructor injection via `deserializeErrors()`, CVE-2026-53669 open redirect via backslash in `<Link>` and `useNavigate`, plus CVE-2026-53668 on react-router-dom). All are fixed only in 7.18.0 with no 6.x backport, so clearing them is a v6 to v7 migration across twenty-front, twenty-ui and twenty-shared and deserves its own PR.
112 lines
18 KiB
JSON
112 lines
18 KiB
JSON
{
|
|
"private": true,
|
|
"devDependencies": {
|
|
"@nx/jest": "22.7.5",
|
|
"@nx/js": "22.7.5",
|
|
"@nx/react": "22.7.5",
|
|
"@nx/storybook": "22.7.5",
|
|
"@nx/vite": "22.7.5",
|
|
"@nx/web": "22.7.5",
|
|
"@types/react": "^19.2.0",
|
|
"@types/react-dom": "^19.2.0",
|
|
"@yarnpkg/types": "^4.0.0",
|
|
"concurrently": "^8.2.2",
|
|
"http-server": "^14.1.1",
|
|
"nx": "22.7.5",
|
|
"oxfmt": "0.50.0",
|
|
"tsx": "^4.17.0",
|
|
"verdaccio": "^6.3.1"
|
|
},
|
|
"engines": {
|
|
"node": "^24.5.0",
|
|
"npm": "please-use-yarn",
|
|
"yarn": ">=4.0.2"
|
|
},
|
|
"license": "AGPL-3.0",
|
|
"name": "twenty",
|
|
"packageManager": "yarn@4.13.0",
|
|
"resolutions": {
|
|
"@module-federation/dts-plugin/undici": "^7.29.0",
|
|
"miniflare/undici": "^7.29.0",
|
|
"e2b/undici8": "npm:undici@^8.9.0",
|
|
"next/sharp": "^0.35.3",
|
|
"nx/form-data": "4.0.6",
|
|
"zapier-platform-core/form-data": "4.0.6",
|
|
"@nestjs/platform-express/multer": "2.2.0",
|
|
"@nestjs/graphql/ws": "8.21.0",
|
|
"@remote-dom/react/@types/react": "^19.2.0",
|
|
"graphql": "16.8.1",
|
|
"graphql-redis-subscriptions/ioredis": "5.10.1",
|
|
"@types/qs": "6.9.16",
|
|
"@opentelemetry/api": "1.9.1",
|
|
"chokidar": "^3.6.0",
|
|
"tmp": "^0.2.7",
|
|
"@mintlify/previewing/tar": "npm:^7.5.16",
|
|
"@angular-devkit/core": "19.2.24",
|
|
"yeoman-environment": "6.0.1",
|
|
"express/qs": "6.15.2",
|
|
"@cypress/request/qs": "6.15.2",
|
|
"body-parser/qs": "6.15.2",
|
|
"next/postcss": "8.5.23",
|
|
"sockjs/uuid": "11.1.1",
|
|
"@cypress/request/uuid": "11.1.1",
|
|
"googleapis-common/uuid": "11.1.1",
|
|
"googleapis/googleapis-common": "8.0.1",
|
|
"@cyntler/react-doc-viewer/ajv": "8.20.0",
|
|
"@mintlify/cli/js-yaml": "4.3.1",
|
|
"@mintlify/common/js-yaml": "4.3.1",
|
|
"@mintlify/common/postcss": "8.5.23",
|
|
"@mintlify/prebuild/js-yaml": "4.3.1",
|
|
"@mintlify/previewing/js-yaml": "4.3.1",
|
|
"@mintlify/scraping/js-yaml": "4.3.1",
|
|
"@mintlify/validation/js-yaml": "4.3.1",
|
|
"@verdaccio/config/js-yaml": "4.3.1",
|
|
"front-matter/js-yaml": "4.3.1",
|
|
"@istanbuljs/load-nyc-config/js-yaml": "4.3.1",
|
|
"@react-email/ui/esbuild": "0.28.1",
|
|
"react-email/esbuild": "0.28.1",
|
|
"@lingui/cli/esbuild": "0.28.1",
|
|
"@opennextjs/aws/esbuild": "0.28.1",
|
|
"storybook/esbuild": "0.28.1",
|
|
"zapier-platform-cli/esbuild": "0.28.1",
|
|
"front-matter@npm:4.0.2": "patch:front-matter@npm%3A4.0.2#~/.yarn/patches/front-matter-npm-4.0.2-e1cc0efa69.patch"
|
|
},
|
|
"//resolutions": "Each entry is load-bearing: it forces a version OUTSIDE some parent's declared range where no fixed upstream release exists; remove each once its blocker ships. @module-federation/dts-plugin/undici + miniflare/undici ^7.29.0 -> five undici advisories with in-major fixes (6.28.0 / 7.29.0 / 8.9.0): CVE-2026-13697 / GHSA-4cwx-7wf7-3272 (critical, cross-user information disclosure + parse-time crash via degenerate private cache directives) and CVE-2026-14643 / GHSA-jr45-8vmc-qm54, both >=7.0.0 <7.29.0 and >=8.0.0 <8.9.0, plus CVE-2026-15157 / GHSA-m8rv-5g2x-5cg5, CVE-2026-16728 / GHSA-8xcm-r25x-g524 and CVE-2026-16729 / GHSA-v3r7-h72x-cjcm (those three also <6.28.0). ^7.29.0 also still covers the six 7.28.0-fixed advisories the previous dts-plugin/undici ^7.28.0 entry was added for (GHSA-pr7r-676h-xcf6, GHSA-35p6-xmwp-9g52, GHSA-p88m-4jfj-68fv, GHSA-g8m3-5g58-fq7m, GHSA-hm92-r4w5-c3mj, GHSA-vmh5-mc38-953g). @module-federation/dts-plugin 2.5.1 pins undici 7.24.7 exact (latest 2.8.1 pins 7.28.0 exact, still vulnerable; transitive via @module-federation/cli + enhanced) and miniflare pins 7.28.0 exact (latest 4.x and the 5-alpha still do; itself exact-pinned by wrangler), so no parent upgrade carries the fix for either; both scoped ^7.29.0 to stay inside major 7 -- no v8 API jump -- and every other consumer resolves a fixed version naturally within its own declared range: e2b's undici ^7.28.0 -> 7.29.0, node-gyp 12.4.0's ^6.25.0 -> 6.28.0, node-gyp 13's ^8.4.1 and jsdom 30's ^8.9.0 -> 8.9.0. Drop each once its pinner depends on undici >=7.29.0. e2b/undici8 npm:undici@^8.9.0 -> e2b additionally ships an OPTIONAL ALIAS dependency undici8 = npm:undici@8.8.0 exact (still 8.8.0 in latest 2.38.0), inside the >=8.0.0 <8.9.0 range of all five advisories above; alias descriptors are keyed by the alias name, so plain undici resolution keys cannot reach it, hence the alias-form entry; drop once e2b aliases undici8 to undici >=8.9.0. next/sharp ^0.35.3 -> GHSA-f88m-g3jw-g9cj (sharp inherits four libvips CVEs: CVE-2026-33327/33328/35590/35591, vulnerable <0.35.0, fixed 0.35.0): every stable next pins sharp ^0.34.5 (the fix lands in next 16.3.0, currently held back by the 3d npmMinimalAgeGate, and @react-email/ui exact-pins next 16.2.6 regardless); scoped to next because next's copy ships in scanned images -- twenty-sdk's direct sharp is bumped to ^0.35.3 in its own package.json and miniflare (0.35.2) is >=0.35.0 on its own; @argos-ci/core 6.1.0 also resolves sharp 0.34.5 but is CI-only visual-testing tooling that never ships in an image and is deliberately NOT refreshed: @argos-ci/storybook 6.2.x bundles @argos-ci/vitest, which fails the storybook CI shards on pre-existing unhandled monaco-editor CDN worker errors that vitest otherwise tolerates (bump argos + handle those errors together, separately); sharp 0.33.5 (favicons + @mintlify/prebuild, website/docs build tooling) sits in the advisory range but is not present in the scanned prod images (only 0.34.5 was flagged) and favicons caps sharp <0.34, so it is left to its parents. Drop once twenty-website's next range resolves >=16.3.0 past the age gate and @react-email/ui moves off next 16.2.x. nx/form-data + zapier-platform-core/form-data 4.0.6 -> CVE-2026-12143 / GHSA-hmw2-7cc7-3qxx (form-data CRLF injection via unescaped multipart field names and filenames, vulnerable >=4.0.0 <4.0.6); nx 22.7.5 and zapier-platform-core 19.0.0 each hard-pin form-data 4.0.5 exact (no caret, both still 4.0.5 in their latest) so no parent upgrade carries the fix; scoped to those two as the sole 4.0.5 pinners -- every other form-data consumer resolves 4.0.6 naturally via its ^4.0.x range, so both pins dedupe onto it; drop once nx and zapier-platform-core depend on form-data >=4.0.6. @nestjs/platform-express/multer 2.2.0 -> CVE-2026-5038 & CVE-2026-5079 (multer DoS); @nestjs/platform-express hard-pins multer 2.1.1 exact (no caret, still 2.1.1 in latest 11.1.27) so no parent upgrade carries the fix; scoped to nest as the sole multer consumer; drop once @nestjs/platform-express depends on multer >=2.2.0. @nestjs/graphql/ws 8.21.0 -> CVE-2026-48779; @nestjs/graphql (already latest 13.4.2, only newer is the 14.0.0-next prerelease) pins ws 8.20.1 exact (no caret) so no parent upgrade carries the fix; scoped to @nestjs/graphql as the sole pinner of the vulnerable ws -- the scoped key matches both its npm and patch: locator instances, and every other ws consumer resolves 8.21.0 naturally; drop once @nestjs/graphql depends on ws >=8.21.0. @remote-dom/react/@types/react ^19.2.0 -> React type-identity dedup, SCOPED to @remote-dom/react only (every other package resolves @types/react 19 naturally from the workspace ^19.2.0 ranges). @remote-dom/react (transitive via twenty-front-component-renderer) lists @types/react ^18 in its own dependencies and nests its own copy; React 18 and 19 declare ReactNode differently (19 adds bigint + Promise<AwaitedReactNode>, drops ReactFragment's {}), so the two copies are mutually non-assignable and break twenty-front's typecheck (~156 TS2322 errors). Range-aligning our own packages can't fix a third-party's transitive @types pin, hence this single scoped override (only @types/react splits; runtime react/react-dom are peer-deps that converge naturally, and @types/react-dom does not nest a copy). Drop once @remote-dom/react widens @types/react to ^19 (latest 1.2.2 still pins ^18; tracked upstream in Shopify/remote-dom#153). graphql 16.8.1 -> singleton pin held below msw's ^16.12.0 dep and @nestjs/graphql's ^16.11.0 peer; drop after a validated repo-wide bump to latest 16.x; graphql-redis-subscriptions/ioredis 5.10.1 -> TS type-identity dedup: twenty-server passes its ioredis client into RedisPubSub, so this must equal the exact ioredis version pinned by twenty-server and bullmq (bump in lockstep); @types/qs 6.9.16 -> holdback below the 6.9.17 ParsedQs typing break (node-saml wants ^6.9.18); @opentelemetry/api 1.9.1 -> singleton guard for the NoopMeterProvider bug (#20231): ai 6.0.x pins 1.9.0 exact vs @sentry/node ^1.9.1, drop when workspace ai >=6.0.178 AND @scalar/agent-chat moves off ai 6.0.33; chokidar ^3 -> NestJS CLI watch needs fsevents on macOS, removed in chokidar 4/5 (#20316); tmp ^0.2.7 -> CVE, zapier-platform-cli 19 (latest) pins 0.2.5 and inquirer 7/8's external-editor wants ^0.0.33; @mintlify/previewing/tar ^7.5.16 -> tar PAX-header file-smuggling CVE GHSA-vmf3-w455-68vh (node-tar <=7.5.15, fixed 7.5.16); @mintlify/previewing exact-pins tar 7.5.15 with no fixed upstream release (latest 4.0.1163 still pins it), pulled via mintlify in twenty-docs; scoped as the sole tar holdout below 7.5.16 (every other tar parent permits 7.5.16 within its declared range and resolves there naturally), drop once @mintlify/previewing ships tar >=7.5.16; @angular-devkit/core 19.2.24 -> picomatch CVE, blocked on @nestjs/cli >11.0.23 fixing the dist/src output regression (repo held at 11.0.16); yeoman-environment 6.0.1 -> CVE, zapier-platform-cli 19 (latest) pins 4.4.3; express/qs + @cypress/request/qs + body-parser/qs 6.15.2 -> qs CVE-2026-8723 / GHSA-q8mj-m7cp-5q26 (>=6.11.1 <=6.15.1, fixed 6.15.2) for old express 4.22.x pinned by @mintlify/previewing and verdaccio: express's direct qs (express/qs), verdaccio's @cypress/request 3.0.10 qs (@cypress/request/qs), and express 4.x's bundled body-parser 1.20.4 which pins qs ~6.14.0 (body-parser/qs); the caret-range qs consumers all dedupe to 6.15.2 naturally; drop once @mintlify/previewing + verdaccio move off express 4.x; next/postcss + @mintlify/common/postcss 8.5.23 -> postcss CVEs, latest GHSA-r28c-9q8g-f849 (path traversal in previous source map auto-loading via sourceMappingURL, arbitrary .map file disclosure, vulnerable <=8.5.17, fixed 8.5.18); every stable next pins postcss 8.4.31 exact (still 8.4.31 in latest 16.2.12, fix only in 16.3.0 canaries; @react-email/ui also pins next 16.2.6) and @mintlify/common pins 8.5.14 exact (still 8.5.14 in latest 1.0.1051), so no parent upgrade carries the fix; scoped to those two as the sole exact pinners -- the caret consumers (^8.4.38, ^8.4.47, ^8.5.15) dedupe onto 8.5.23 naturally; drop each once its pinner depends on postcss >=8.5.18; <pkg>/uuid 11.1.1 -> uuid CVE for parents pinning uuid <11 with no fixed release (sockjs dormant since 2021; @cypress/request 3.0.10 via verdaccio; googleapis 105 -> common 8 drops uuid but needs the googleapis >=152 migration). Preserves the intentional uuid 13.x; @cyntler/react-doc-viewer/ajv 8.20.0 -> CVE, upstream (latest 1.17.1) pins ajv ^7 but never imports it, forcing v8 is safe; */esbuild 0.28.1 -> two esbuild advisories both fixed in 0.28.1: the Deno-module binary-integrity RCE GHSA-gv7w-rqvm-qjhr (vulnerable >=0.17.0 <0.28.1) and the earlier dev-server path-traversal GHSA-g7r4-m6w7-qqqr (Windows, >=0.27.3 <0.28.1). The Deno advisory's range covers every esbuild <0.28.1, so it re-exposed older transitive copies too. Preference is to fix by upgrading the parent, not by resolution -- done where it works: @size-limit/preset-small-lib+size-limit (now ^12.1.0, pin esbuild ^0.28.0) and wrangler (bumped within ^4.0.0 to 4.102.0, which pins esbuild 0.28.1) were bumped and resolve to 0.28.1 on their own, NO resolution needed. The six resolutions below are for parents that cannot be cleanly upgraded. Five pin a vulnerable esbuild OUTSIDE the 0.28.1 range in their latest release: @react-email/ui exact-pins 0.28.0 (still 0.28.0 in latest 6.6.0); @opennextjs/aws exact-pins 0.25.4 (still 0.25.4 in latest 4.0.3); zapier-platform-cli exact-pins 0.25.8 (latest 19.0.0); @lingui/cli pins ^0.25.1 -> caps <0.26 (still ^0.25.1 in latest 6.3.0); storybook pins a range topping out at ^0.27.0 -> caps <0.28 (still capped in latest 10.4.4). react-email allows ^0.28.0 but the npmMinimalAgeGate down-selects it to the still-vulnerable 0.28.0 until 0.28.1 ages past the gate (published 2026-06-11). tsx needs NO resolution: its ^4.x ranges resolve to 4.22.x which pins esbuild ~0.28.0 -> 0.28.1 on its own. (tsx had briefly been pinned to 4.21.0 because tsx 4.22's --import tsx/esm loader feeds esbuild-downleveled enums into jest's type-checking ts-node config compiler, yielding a spurious TS7022 in server-integration-test; that is now fixed at the source by dropping --import tsx/esm from the integration jest invocation in twenty-server project.json (it had been swept in by the Storybook 10 upgrade and is not needed there): ts-node alone now compiles the config + globalSetup, so there is no esbuild enum downleveling to trip TS7022 and decorator metadata is still emitted. tsx version is now irrelevant to the tests, so the pin was dropped.) Drop each entry once its parent ships a range that resolves to >=0.28.1 on its own (react-email drops once 0.28.1 clears the age gate). Our own twenty-client-sdk raises its esbuild floor to ^0.28.1 directly in its package.json instead of via a resolution. googleapis/googleapis-common 8.0.1 -> singleton dedup for the googleapis 173 upgrade. googleapis-common 8.0.2 (published 2026-06-04, AFTER googleapis 173 on 2026-05-28) regressed its google-auth-library dep from a range to exact 10.5.0 (and gaxios to exact 7.1.3), while googleapis itself pulls google-auth-library ^10.2.0 (10.7.0); the two mismatched copies make OAuth2Client's type-identity diverge between the client our provider builds (via googleapis -> 10.7.0) and the one gmail/calendar method options expect (via googleapis-common -> 10.5.0), breaking every gmail/calendar service typecheck (TS2322/TS2769). The parents are already at latest (googleapis 173.0.0, googleapis-common 8.0.2) so we cannot fix by upgrading; instead we pin googleapis' googleapis-common back to 8.0.1, the last version with RANGE deps (google-auth-library ^10.1.0, gaxios ^7.0.0-rc.4) -- and the version googleapis 173 originally shipped against. Ranges resolve to the same hoisted versions googleapis uses, so google-auth-library AND gaxios both collapse to a single copy with no further resolution (a global google-auth-library pin would only dedup one of the two). Scoped to googleapis since it is the sole googleapis-common 8.x consumer. Drop once googleapis-common 8.0.3+ restores range deps or googleapis bumps to a common that does. @mintlify/{cli,common,prebuild,previewing,scraping,validation}/js-yaml + @verdaccio/config/js-yaml 4.3.1 -> CVE-2026-53550 / GHSA-h67p-54hq-rp68 (js-yaml quadratic-complexity DoS in YAML merge-key handling via repeated aliases, vulnerable <=4.1.1, fixed 4.2.0), its follow-up CVE-2026-59869 / GHSA-52cp-r559-cp3m (merge-key chains force quadratic CPU, vulnerable 4.x <4.3.0, fixed 4.3.0) and GHSA-5p4m-2wfm-xmqj (the same quadratic CPU consumption in !!omap resolution, registered in the default schema so plain yaml.load is affected, vulnerable 4.x <4.3.1, fixed 4.3.1); these seven packages each hard-pin js-yaml 4.1.1 exact (no caret, still 4.1.1 in their latest) so no parent upgrade carries the fix; scoped to those seven as the sole 4.1.1 pinners -- the cosmiconfig-based caret consumers (@graphql-codegen/cli, @lingui/cli, @lingui/vite-plugin, @wyw-in-js/vite, vite-plugin-svgr, all via cosmiconfig ^4.1.0) shared that single 4.1.1 copy and dedupe onto 4.3.0 once it is lifted. Drop these seven once they ship js-yaml >=4.3.1. The remaining js-yaml 3.x holders -- front-matter@4.0.2 (via mintlify in twenty-docs) and @istanbuljs/load-nyc-config@1.1.0 (via babel-plugin-istanbul coverage), both declaring js-yaml ^3.13.1 -> 3.14.2 with no fixed upstream release -- are also forced to 4.3.1 via scoped pins (front-matter/js-yaml + @istanbuljs/load-nyc-config/js-yaml), evicting the last js-yaml 3.14.2 copy and closing alert #1504. load-nyc-config calls yaml.load (present and safe-by-default in 4.x) so its pin alone suffices. front-matter's default loader called the safeLoad API that 4.x removed, so it is also patched (front-matter@npm:4.0.2 -> .yarn/patches/front-matter-npm-4.0.2-e1cc0efa69.patch) to set loader = parser.load (safe-by-default in 4.x; safeLoad is gone and 4.x core has no unsafe/full schema, so the old allowUnsafe ternary is dead). The version move stays a separate resolution because a yarn patch only rewrites a package's files, not its resolved dependency graph -- patching front-matter's own js-yaml range does not change what yarn resolves. Drop the patch + both pins once front-matter/mintlify and load-nyc-config ship js-yaml >=4.",
|
|
"version": "0.2.1",
|
|
"nx": {},
|
|
"scripts": {
|
|
"docs:generate": "tsx packages/twenty-docs/scripts/generate-docs-json.ts",
|
|
"docs:generate-navigation-template": "tsx packages/twenty-docs/scripts/generate-navigation-template.ts",
|
|
"docs:generate-paths": "tsx packages/twenty-docs/scripts/generate-documentation-paths.ts",
|
|
"docs:prune-orphans": "tsx packages/twenty-docs/scripts/prune-orphan-translations.ts",
|
|
"start": "npx concurrently --kill-others 'npx nx run-many -t start -p twenty-server twenty-front' 'npx wait-on tcp:3000 && npx nx run twenty-server:worker'"
|
|
},
|
|
"workspaces": {
|
|
"packages": [
|
|
"packages/twenty-front",
|
|
"packages/twenty-server",
|
|
"packages/twenty-emails",
|
|
"packages/twenty-ui",
|
|
"packages/twenty-utils",
|
|
"packages/twenty-zapier",
|
|
"packages/twenty-website",
|
|
"packages/twenty-docs",
|
|
"packages/twenty-e2e-testing",
|
|
"packages/twenty-shared",
|
|
"packages/twenty-sdk",
|
|
"packages/twenty-front-component-renderer",
|
|
"packages/twenty-client-sdk",
|
|
"packages/twenty-cli",
|
|
"packages/create-twenty-app",
|
|
"packages/twenty-codex-plugin",
|
|
"packages/twenty-oxlint-rules",
|
|
"packages/twenty-claude-skills"
|
|
]
|
|
},
|
|
"prettier": {
|
|
"singleQuote": true,
|
|
"trailingComma": "all",
|
|
"endOfLine": "lf"
|
|
}
|
|
}
|