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

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 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

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

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