fix(deps): patch next-mdx-remote and opentelemetry CVEs

[waleedlatif1]

Summary

• bump next-mdx-remote 5.0.0 → 6.0.0 — resolves GHSA-g4xw-jxrg-5f6m / CVE-2026-0969 (arbitrary code execution in MDX serialize; high, CVSS 8.8). v6 introduces blockJS: true default; audited all 9 blog posts and confirmed no MDX uses raw JS expressions outside fenced code blocks
• bump @opentelemetry/sdk-node and @opentelemetry/exporter-trace-otlp-http 0.200.0 → 0.217.0 — resolves GHSA-q7rr-3cgh-j5r3 / CVE-2026-44902 (Prometheus exporter DoS via malformed URL; high, CVSS 7.5). Our process uses the OTLP HTTP trace exporter and does not bind the Prometheus port, so actual exposure was already nil — patch closes the dependabot alert
• align @opentelemetry/sdk-trace-base, sdk-trace-node, resources to ^2.7.0 so all @opentelemetry/* packages resolve to a single @opentelemetry/core@2.7.1 instance (prevents silent breakage from mixed core versions)

Type of Change

• Bug fix

Testing

Tested manually — tsc --noEmit passes, lockfile shows a single top-level @opentelemetry/core@2.7.1 and next-mdx-remote@6.0.0. Will smoke-test blog rendering and OTel span export in dev before merge.

Note: dependabot #112 (mermaid) deliberately not included — mermaid@11.15.0 was blocked by the repo's 3-day minimum-release-age policy. Will ship in a follow-up once it ages in.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	May 11, 2026 8:50pm

[cursor]

PR Summary

Medium Risk
Dependency upgrades for next-mdx-remote and the OpenTelemetry stack can change MDX compilation behavior and telemetry exporting at runtime, so there’s some regression risk despite being security-motivated.

Overview
Upgrades next-mdx-remote to ^6.0.0 to pick up security fixes affecting MDX compilation/serialization.

Bumps the app’s OpenTelemetry dependencies (notably @opentelemetry/sdk-node, @opentelemetry/exporter-trace-otlp-http, and related resources/sdk-trace-* packages) to newer 0.217.x/2.7.x versions and refreshes bun.lock accordingly to align transitive OTel packages.

^{Reviewed by Cursor Bugbot for commit e7e6450. Configure here.}

[greptile-apps]

Greptile Summary

This PR patches two high-severity CVEs by bumping next-mdx-remote from 5.0.0 to 6.0.0 and the entire @opentelemetry/* family from 0.200.0 to 0.217.0, along with aligning transitive packages to eliminate mixed @opentelemetry/core version conflicts.

• next-mdx-remote 5→6 (GHSA-g4xw-jxrg-5f6m): The upgrade shifts to v6's blockJS: true default in compileMDX. The existing codebase in registry.ts already avoids MDX-level imports entirely—custom components are injected externally via mergedComponents—so the new default is strictly safer and all 9 blog posts remain unaffected.
• OpenTelemetry 0.200.0→0.217.0 (GHSA-q7rr-3cgh-j5r3): The OTel family upgrade pulls in several transitive major-version bumps—protobufjs 7→8, import-in-the-middle 1→3, require-in-the-middle 7→8—all driven by the OTel SDK's own dependency graph. sdk-trace-base and sdk-trace-node also move from exact pins to caret ranges (^2.7.0) to prevent version fragmentation.

Confidence Score: 4/5

Safe to merge once the smoke-test confirms blog rendering and OTel span export still work; no application logic was changed.

The lockfile correctly unifies all @opentelemetry/core instances to 2.7.1 and tsc passes. The main open item is that smoke testing is still pending per the PR description, and the import-in-the-middle 1→3 jump is large enough that silently broken auto-instrumentation might not surface until a real OTel trace is exercised in dev or staging.

bun.lock — the import-in-the-middle and require-in-the-middle major-version changes; apps/sim/instrumentation-node.ts should be exercised in dev to confirm span export still works after the OTel upgrade.

Important Files Changed

Filename	Overview
apps/sim/package.json	Targeted version bumps for next-mdx-remote and @opentelemetry/* packages; sdk-trace-base and sdk-trace-node moved from exact pins to caret ranges intentionally to align the OTel core version
bun.lock	Lockfile updated to resolve all @opentelemetry/* to a single @opentelemetry/core@2.7.1; several transitive packages underwent major-version jumps (protobufjs 7→8, import-in-the-middle 1→3) as driven by the OTel SDK upgrade

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    subgraph MDX["next-mdx-remote (CVE-2026-0969)"]
        NMR5["next-mdx-remote@5.0.0"]
        NMR6["next-mdx-remote@6.0.0\nblockJS: true default"]
        NMR5 -- "5 to 6" --> NMR6
    end
    subgraph OTEL["@opentelemetry/*"]
        OTEL1["sdk-node + exporter-trace-otlp-http\n0.200.0 to 0.217.0"]
        CORE1["@opentelemetry/core 2.0.0 to 2.7.1"]
        PROTO["protobufjs 7.x to 8.x"]
        IITM["import-in-the-middle 1.x to 3.x"]
        OTEL1 --> CORE1
        OTEL1 --> PROTO
        OTEL1 --> IITM
    end
    subgraph USAGE["App code (unchanged)"]
        INSTR["instrumentation-node.ts"]
        REG["lib/blog/registry.ts compileMDX"]
    end
    NMR6 --> REG
    OTEL1 --> INSTR

Loading

Comments Outside Diff (2)

1. apps/sim/lib/blog/registry.ts, line 170-175 (link)

   The v6 upgrade makes blockJS: true the default, which is the change that closes CVE-2026-0969. The compileMDX call currently inherits that behavior implicitly. Pinning it explicitly in options ensures the security guarantee survives if a future developer adds an override thinking they're unlocking MDX features, and makes it self-documenting that the restriction is intentional.

2. bun.lock, line 171 (link)

   Transitive major-version jumps in module-patching libs

   import-in-the-middle moves from 1.15.0 → 3.0.1 and require-in-the-middle from 7.5.2 → 8.0.1. Both libraries are used by @opentelemetry/instrumentation to monkey-patch Node.js module loading at startup. These are major-version bumps and carry their own breaking changes; if OTel instrumentation silently stops patching modules after the upgrade, span creation from auto-instrumented packages would fall through without any error. Confirming that the startup smoke-test exercises at least one auto-instrumented code path will catch this.

_{Reviews (1): Last reviewed commit: "fix(deps): patch next-mdx-remote and ope..." | Re-trigger Greptile}