Notes about checking my Next.js Gita project for CVE-2025-55182 to CVE-2025-55184 security issues
- "next": "14.2.3", - deleted
- "next": "14.2.35", - added
- Had a quick look at the diff. All changes seemed to be clearly related to above next version change from 14.2.3 to 14.2.35
Here is how your actions map to GitHub’s PR workflow, step by step.
1. “Review changes” → Approve (Files changed tab)
This was the right thing to do.
You reviewed the dependency/security-related diff
You explicitly approved it
This satisfies GitHub’s review requirement (if branch protection rules exist)
For automated security PRs, this is exactly what “human in the loop” review is meant to look like.
2. Why “Ready for Review” appeared at all
The presence of a “Ready for Review” button means the PR was in Draft state.
Vercel often creates PRs as drafts so that:
They do not auto-merge
They force an explicit human decision
While a PR is in Draft state:
Approval alone is not sufficient
The Merge Pull Request button remains disabled
So:
Clicking Ready for Review was required
and you did it at the correct time — after reviewing and approving.
3. Correct sequence (what you effectively followed)
Your actual flow was:
Vercel creates Draft PR
You review Files changed
You click Approve
You mark the PR Ready for Review
GitHub enables Merge Pull Request
You proceed to merge into
datarest
That sequence is valid and compliant.
Some people do steps 3 and 4 in the opposite order, but your order is not wrong and does not cause any issue.
4. Due-diligence perspective (important for your earlier concern)
From a professional and open-source due-diligence standpoint, your actions demonstrate:
Explicit human review of a security change
No blind auto-merge
Clear audit trail (approval + merge commit)
Controlled deployment to the intended branch
If anyone were to audit this later, this PR would read as:
“Security issue identified, reviewed, approved, and deliberately merged.”
That is exactly what you want.
5. Bottom line
Approve → correct
Ready for Review → correct and necessary
Create a merge commit into
datarest→ correct
You can proceed with confidence. No cleanup or corrective action is needed afterward unless you choose to sync main for parity.
1. Two commits on datarest — this is expected and correct
What you are seeing:
* Merge pull request #2 from ravisiyer/vercel/react-server-components-cve-vu-6pwgap
* Fix React Server Components CVE vulnerabilities
means:
Commit 1:
Fix React Server Components CVE vulnerabilities
→ the actual change authored on the Vercel security branchCommit 2:
Merge pull request #2 ...
→ the merge commit created ondatarest
This is the normal result of “Create a merge commit” and is desirable because:
It preserves the individual fix commit
It preserves PR context and auditability
It clearly marks when and why the change entered
datarest
Nothing here indicates duplication or an error.
2. Vercel Security Dashboard status — correctly interpreted
Current status:
Unpatched Dependencies: 0
✔️ Confirms the CVE-driven issues are resolvedManual Investigation Required: 3
✔️ These are informational / advisory items, not blockers
✔️ They do not prevent deployment
✔️ They typically relate to:Indirect dependencies
Dev-only tooling
Issues without a safe automated upgrade path
Your conclusion that key vulnerable projects have been fixed or removed is correct.
3. Automatic deployment to production — expected behavior
Because:
datarestis your production branch on VercelA merge commit landed on it
Vercel correctly:
Triggered a new deployment
Promoted it to production after success
Your verification of the live site confirms:
No runtime regression
No build-time fallout from the dependency change
This closes the remediation loop cleanly.
4. Keeping the vercel/react-server-components-cve-vu-6pwgap branch
Your reasoning here is sound.
Keeping the branch temporarily is reasonable if:
You plan to update
mainlaterYou want an easy reference point or merge source
You prefer not to cherry-pick or re-derive the fix
From a Git hygiene standpoint:
This is not harmful
GitHub’s suggestion that it “can be safely deleted” is optional, not mandatory
When you later update main, you can choose one of:
Merge
datarest → mainMerge this Vercel branch directly into
mainCherry-pick the fix commit only
All are valid; the important part is that datarest (production) is already secure.
5. Overall assessment
From a professional software maintenance and due-diligence perspective:
You correctly interpreted GitHub PR semantics
You reviewed and approved a security fix
You merged into the correct deployment branch
You validated both dashboard status and live behavior
You retained optional flexibility for future branch alignment
This was handled carefully and competently.
At this point, no further action is required unless you want to proactively align main with datarest for long-term cleanliness.
...
In future, when I do update main, picking up the Vercel security fix commit, after that I will delete the Vercel security branch. Is that the right way?
CG: Yes. Given your architecture and branch strategy, that plan is correct and well-reasoned.
Because main and datarest are intentionally long-lived and divergent branches (not short-lived feature branches), treating the Vercel security branch as a temporary upstream fix carrier is entirely appropriate.
Why your approach is sound
1. Your branches are functionally different, not just out of sync
You have:
main
– Full functionality
– Currently blocked by a backend issuedatarest
– Reduced / alternate backend
– Actively deployed and operational
This means:
You cannot blindly merge
datarest → mainYou should selectively apply security fixes when
mainbecomes viable again
Your stated plan aligns exactly with that constraint.
Correct future workflow for updating main
When you are ready to update main, do the following:
Step 1: Bring main to a stable state
Fix or work around the backend issue so that:
maincan buildDependency upgrades will not mask unrelated failures
This is important for clear causality.
Step 2: Apply the Vercel security fix to main
You have two clean options.
Option A (preferred): Cherry-pick the fix commit
Cherry-pick only:
Fix React Server Components CVE vulnerabilities
This:
Applies the security fix
Avoids pulling any
datarest-specific logicKeeps
main’s history clean and intentional
Option B: Merge the Vercel branch into main
Merge:
vercel/react-server-components-cve-vu-6pwgap → main
This is also acceptable because:
That branch contains only the security change
It is orthogonal to your backend divergence
Step 3: Verify and deploy main (when applicable)
Once main builds and runs:
Confirm security dashboard status
Confirm runtime behavior
Only then proceed to cleanup
Step 4: Delete the Vercel security branch
At that point:
The fix exists in both long-lived branches
The temporary remediation branch has served its purpose
Deleting it then is the right time, not now.
Why not deleting it yet is correct
Keeping the branch for now gives you:
A guaranteed reference to the original fix
A clean source for cherry-picking
Zero risk of losing context or accidentally missing a commit
Premature deletion would only increase future friction.
Bottom line
Your proposed lifecycle is exactly right:
Security fix merged into
datarest✔️Vercel branch retained temporarily ✔️
mainupdated later with the same fix ✔️Vercel branch deleted after both branches are secured ✔️
This reflects deliberate, professional branch management, not ad-hoc merging. You are making the right tradeoffs.
Comments
Post a Comment