TL; DR
React2Shell (CVE-2025-55182) ສ້າງຄວາມວິພາກວິຈານ ຄວາມສ່ຽງຂອງ RCE ໃນທົ່ວ ອົງປະກອບເຊີບເວີ React (RSC) ແລະ ຂອບການທີ່ຝັງພວກມັນ, ລວມທັງ ຕໍ່ໄປເນື່ອງຈາກວ່າຊ່ອງໂຫວ່ດັ່ງກ່າວອາໄສຢູ່ພາຍໃນ RSC ຊັ້ນ serialization ແລະ deserialization, ຜູ້ໂຈມຕີສາມາດສົ່ງຄຳຮ້ອງຂໍ HTTP ແລະ trigger ທີ່ສ້າງຂຶ້ນມາ ການປະຕິບັດລະຫັດຈາກໄລຍະໄກທີ່ບໍ່ໄດ້ຮັບການພິສູດຢືນຢັນ, ເຖິງແມ່ນວ່າທີມຈະໃຊ້ການຕັ້ງຄ່າເຟຣມເວີກເລີ່ມຕົ້ນກໍຕາມ. ຕໍ່ໄປ ແອັບພລິເຄຊັນປະເຊີນກັບຄວາມສ່ຽງສູງສຸດເພາະວ່າພວກມັນຍອມຮັບແລະປະມວນຜົນ React ການບິນ payloads ຜ່ານ HTTP ໂດຍຄ່າເລີ່ມຕົ້ນ.
ຂໍ້ບົກຜ່ອງດັ່ງກ່າວສົ່ງຜົນກະທົບຕໍ່ຫຼາຍລຸ້ນຂອງ ແພັກເກດເຊີບເວີ React, ແລະ ຜູ້ໂຈມຕີບໍ່ຕ້ອງການເຫດຜົນຂອງແອັບພລິເຄຊັນທີ່ກຳນົດເອງເພື່ອໃຊ້ປະໂຫຍດຈາກມັນ. ນັກຄົ້ນຄວ້າຄວາມປອດໄພສະແດງໃຫ້ເຫັນຄວາມໜ້າເຊື່ອຖືເກືອບ 100%, ແລະ ການສະແກນໃນຕອນຕົ້ນເປີດເຜີຍວ່າສະພາບແວດລ້ອມຄລາວຫຼາຍແຫ່ງມີຄວາມສ່ຽງຕໍ່ການໂຈມຕີ. ຕໍ່ໄປ ຕົວຢ່າງ. ທີມຕ່າງໆຕ້ອງແກ້ໄຂທັນທີ ແລະ ກວດສອບລະບົບນິເວດຢ່າງຄົບຖ້ວນຂອງພວກມັນເພື່ອຫຼຸດຜ່ອນຂະໜາດ ຄວາມສ່ຽງດ້ານ RCE ຂອງ React2Shell (CVE-2025-55182).
ຊ່ອງໂຫວ່ອັນຕະລາຍທີ່ລາຍງານຜ່ານໂຄງການ bug bounty ຂອງ Meta ໃນວັນທີ 29 ພະຈິກ ໄດ້ກະຕຸ້ນໃຫ້ເກີດການຕອບສະໜອງຢ່າງຮີບດ່ວນໃນທົ່ວລະບົບນິເວດ JavaScript.
ຖືກອອກແບບ CVE-2025-55182, ເປີດເຜີຍໃນວັນທີ 3 ທັນວາ ເຊິ່ງປະຈຸບັນເອີ້ນວ່າ React2Shell ເປັນຊ່ອງໂຫວ່ທີ່ມີຄວາມຮຸນແຮງສູງສຸດທີ່ສົ່ງຜົນກະທົບຕໍ່ ອົງປະກອບເຊີບເວີ React ພ້ອມກັບເຟຣມເວີກທີ່ລວມເອົາພວກມັນເຂົ້າກັນ. ໃນເບື້ອງຕົ້ນ, ຕົວລະບຸຊ່ອງໂຫວ່ Next.js ແຍກຕ່າງຫາກ (CVE-2025-66478) ໄດ້ຖືກມອບໝາຍ, ແຕ່ຕໍ່ມາ NVD ໄດ້ລວມມັນເຂົ້າກັບ React CVE ຫຼັກເປັນລາຍການຊໍ້າກັນ.
ບັນຫາພື້ນຖານແມ່ນການຈັດການທີ່ບໍ່ປອດໄພຂອງ payload RSC ທີ່ເປັນລຳດັບທີ່ສາມາດກະຕຸ້ນຜ່ານການຮ້ອງຂໍ HTTP. ສິ່ງນີ້ເປີດປະຕູໃຫ້ຜູ້ກະທຳທີ່ເປັນອັນຕະລາຍສົ່ງການຮ້ອງຂໍ HTTP ທີ່ຖືກຫຼອກລວງເຊິ່ງເຮັດໃຫ້ JavaScript ເຮັດວຽກຢູ່ໃນເຊີບເວີໂດຍບໍ່ຮູ້ຕົວຫຼັງຈາກທີ່ຖືກ ຍົກເລີກການແຍກອະນຸກົມໂດຍ React.
CVE-2025-55182 ພາບລວມ
ອົງປະກອບເຊີບເວີ React ໄດ້ຖືກປະສົມປະສານເຂົ້າກັບເຟຣມເວີກທີ່ທັນສະໄໝຢ່າງເລິກເຊິ່ງ, ແລະໃນຫຼາຍໆກໍລະນີແມ່ນຖືກເປີດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ. ເນື່ອງຈາກສິ່ງນີ້, ແອັບພລິເຄຊັນອາດຈະຖືກເປີດເຜີຍຕໍ່ React2Shell (CVE-2025-55182) ເຖິງແມ່ນວ່າພວກເຂົາບໍ່ເຄີຍກຳນົດຈຸດສິ້ນສຸດຂອງໜ້າທີ່ເຊີບເວີຢ່າງຊັດເຈນກໍຕາມ. ການຈັດຕັ້ງປະຕິບັດ RSC ຍັງມີຢູ່, ແລະສິ່ງດຽວນັ້ນກໍພຽງພໍທີ່ຈະເປີດໃຊ້ເສັ້ນທາງລະຫັດທີ່ມີຄວາມສ່ຽງ ແລະ ສ້າງຄວາມສຳຄັນ ຄວາມສ່ຽງຂອງ RCE.
ຂໍ້ບົກຜ່ອງດັ່ງກ່າວເກີດມາຈາກວິທີການທີ່ ໂປໂຕຄອນ React Flightl ປະມວນຜົນ payload ທີ່ມີໂຄງສ້າງບາງຢ່າງ. ເວີຊັນເກົ່າໄດ້ພະຍາຍາມຍ່າງໄປຕາມເສັ້ນທາງວັດຖຸທີ່ສະໜອງໃຫ້ໃນ payload ໂດຍບໍ່ໄດ້ກວດສອບວ່າໂຄງສ້າງນັ້ນຖືກຕ້ອງ ຫຼື ຄາດຫວັງໄວ້. ຜູ້ໂຈມຕີສາມາດຫຼອກລວງຂະບວນການນີ້ ແລະ ໃນທີ່ສຸດກໍສາມາດບັນລຸການປະຕິບັດລະຫັດໃນເຊີບເວີ. ບໍ່ມີການພິສູດຢືນຢັນຕົວຕົນ, ບໍ່ມີການກຳນົດຄ່າພິເສດ, ແລະ ບໍ່ຕ້ອງການເຫດຜົນສະເພາະຂອງແອັບ. ເນື່ອງຈາກບັນຫາມີຢູ່ໃນການຕັ້ງຄ່າທີ່ຕິດຕັ້ງໄວ້ກ່ອນ, standard ການນຳໃຊ້ໄດ້ຖືກເປີດເຜີຍໂດຍບໍ່ຕ້ອງການເງື່ອນໄຂຜິດປົກກະຕິໃດໆ.
ການຂູດຮີດເກີດຂຶ້ນເມື່ອຜູ້ໂຈມຕີສົ່ງຄຳຮ້ອງຂໍ HTTP POST ທີ່ເປັນອັນຕະລາຍເຊິ່ງລະເມີດ “vm.runInThisContext” ຜ່ານການກະທຳຂອງ Server. ໃນຂະນະທີ່ React ບໍ່ໄດ້ເປີດເຜີຍຈຸດສິ້ນສຸດທີ່ມີຄວາມສ່ຽງໂດຍກົງ, Next.js ເຮັດ, ສ້າງເວັກເຕີໂຈມຕີໄລຍະໄກທີ່ແທ້ຈິງ.
Next.js ຮັບເອົາ payload ຂອງ Flight ຈາກການຮ້ອງຂໍໃດໆ, ປະມວນຜົນພວກມັນໂດຍບໍ່ມີການກວດສອບທີ່ຖືກຕ້ອງ, ແລະສົ່ງຕໍ່ໄປຫາ deserializer ຂອງ React. ລະບົບປະຕິບັດຕໍ່ອິນພຸດພາຍນອກເຫຼົ່ານີ້ເປັນທີ່ເຊື່ອຖືໄດ້, ເຮັດໃຫ້ຜູ້ໂຈມຕີສາມາດບັນລຸ ການປະຕິບັດລະຫັດຫ່າງໄກສອກຫຼີກ ຜ່ານຈຸດສິ້ນສຸດທີ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະ ດ້ວຍສິດທິພິເສດຂອງຂະບວນການ Node.js ເຕັມຮູບແບບ ຢູ່ໃນເຊີບເວີເປົ້າໝາຍ.
ຄວາມຮຸນແຮງເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍເພາະວ່າການຕັ້ງຄ່າເລີ່ມຕົ້ນຍັງຄົງມີຄວາມສ່ຽງຕໍ່ React2Shell (CVE-2025-55182) ແລະຜົນໄດ້ຮັບ ຄວາມສ່ຽງຂອງ RCE. A standard ແອັບພລິເຄຊັນ Next.js ທີ່ທ່ານສ້າງດ້ວຍ create-next-app ເປີດເຜີຍຕົວເອງໂດຍບໍ່ຕ້ອງການລະຫັດທີ່ກຳນົດເອງ ຫຼື ການປ່ຽນແປງການຕັ້ງຄ່າໃດໆ. ນັກຄົ້ນຄວ້າຄວາມປອດໄພຢືນຢັນຄວາມໜ້າເຊື່ອຖືເກືອບ 100% ຂອງການໃຊ້ປະໂຫຍດຈາກການຂູດຮີດ ແລະ ລາຍງານວ່າ 39% ຂອງສະພາບແວດລ້ອມຄລາວດໍາເນີນການ instances ທີ່ມີຄວາມສ່ຽງ, ໃນຂະນະທີ່ 44% ຂອງສະພາບແວດລ້ອມທັງໝົດດໍາເນີນການແອັບພລິເຄຊັນ Next.js ທີ່ເປີດເຜີຍຕໍ່ສາທາລະນະທີ່ໄດ້ຮັບຜົນກະທົບຈາກ React2Shell.
ເຂົ້າໃຈການສໍາຜັດກັບ React2Shell
ລຸ້ນທີ່ມີຄວາມສ່ຽງກວມເອົາຫຼາຍລຸ້ນ:
| ອົງປະກອບ | ສະບັບທີ່ໄດ້ຮັບຜົນກະທົບ |
|---|---|
| react-server-dom-webpack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| ເຊີບເວີຕອບໂຕ້ dom-parcel | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| ເຊີບເວີຕອບໂຕ້ dom-turbopack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
ເນື່ອງຈາກຫຼາຍເຟຣມເວີກຝັງການຮອງຮັບ RSC ໄວ້ໃນແກນກາງ, ແອັບພລິເຄຊັນມັກຈະສືບທອດລະຫັດທີ່ມີຄວາມສ່ຽງໂດຍທີ່ບໍ່ຮູ້ຕົວ. ເຟຣມເວີກ ຫຼື bundler ໃດໆທີ່ສົ່ງແພັກເກດເຫຼົ່ານີ້ສາມາດເຮັດໃຫ້ແອັບພລິເຄຊັນມີຄວາມສ່ຽງຕໍ່ React2Shell (CVE-2025-55182) ແລະຄວາມສ່ຽງ RCE ຂອງມັນ. ນັ້ນລວມທັງ:
- Next.js (ເຣົາເຕີແອັບ)
- ຕົວຢ່າງ RSC ຂອງ React Router
- ປລັກອິນ Vite RSC
- ປລັກອິນ Parcel RSC
- ເຣດວູດ SDK
- Waku
- ງານວາງສະແດງ
Next.js ໄດ້ຮັບຜົນກະທົບໂດຍສະເພາະເພາະມັນໃຊ້ຈຸດສິ້ນສຸດທີ່ກ່ຽວຂ້ອງກັບ RSC ຜ່ານ HTTP ໂດຍຄ່າເລີ່ມຕົ້ນ. ເວີຊັນທີ່ເລີ່ມຕົ້ນດ້ວຍ 14.3.0 ການສ້າງ canary, ພ້ອມກັບສ່ວນໃຫຍ່ 15.x ແລະຕົ້ນ 16.x ການປ່ອຍ, ບັນຈຸການຈັດຕັ້ງປະຕິບັດທີ່ມີຄວາມສ່ຽງ. ຜູ້ໃດກໍຕາມທີ່ໃຊ້ canary 14.3.0-canary.77 ຫຼື ຄວນຫຼັງຈາກນັ້ນ ກັບຄືນໄປຫາ 14.x ທີ່ໝັ້ນຄົງ ສາຂາຈົນກວ່າຈະມີການເຜີຍແຜ່ເວີຊັນ Canary ທີ່ໄດ້ຮັບການແກ້ໄຂແລ້ວ.
ເວີຊັນ Next.js ທີ່ໄດ້ຮັບການແກ້ໄຂແລ້ວ ປະກອບດ້ວຍ:
| ອົງປະກອບ | ເວີຊັນທີ່ໄດ້ຮັບການແກ້ໄຂແລ້ວ |
|---|---|
| ຕໍ່ໄປ | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 |
PoC ສາທາລະນະ ແລະ ການກວດສອບທີ່ໜ້າເຊື່ອຖື
ຫຼັງຈາກການເປີດເຜີຍຊ່ອງໂຫວ່, ຫຼັກຖານແນວຄວາມຄິດຫຼາຍຢ່າງທີ່ຄາດວ່າຈະພິສູດໄດ້ເລີ່ມແຜ່ລາມ. ຫຼາຍໆຢ່າງແມ່ນບໍ່ຖືກຕ້ອງ ຫຼື ອີງໃສ່ຂໍ້ສົມມຸດທີ່ບົກຜ່ອງ. ຜູ້ຂຽນຊ່ອງໂຫວ່ຕົ້ນສະບັບ, Lachlan Davidson, ໄດ້ຢືນຢັນຕໍ່ສາທາລະນະຊົນໃນວັນທີ react2shell ວ່າ GitHub PoCs ທີ່ແຜ່ລາມບໍ່ກົງກັບຊ່ອງໂຫວ່ທີ່ແບ່ງປັນເປັນສ່ວນຕົວກັບຜູ້ຮັກສາ React/Next.js ແລະໄດ້ໃຫ້ຂໍ້ມູນຂອງລາວ PoC ຂອງຕົນເອງ.
ບັນຫາໃຫຍ່ຂອງຄວາມພະຍາຍາມໃນສາທາລະນະຊົນໃນຕອນຕົ້ນແມ່ນຄວາມລົ້ມເຫຼວຂອງພວກເຂົາໃນການຮັບຮູ້ວ່າການຂູດຮີດປະສົບຜົນສໍາເລັດຕໍ່ກັບ standard ການນຳໃຊ້ Next.js ໂດຍບໍ່ຕ້ອງການໃຫ້ມີເຫດຜົນສະເພາະຂອງແອັບພລິເຄຊັນ ຫຼື ຟັງຊັນຝັ່ງເຊີບເວີມີຢູ່.
ນັກຄົ້ນຄວ້າດ້ານຄວາມປອດໄພຈາກຫຼາຍອົງກອນໄດ້ເນັ້ນໜັກວ່າການກວດຫາຊ່ອງໂຫວ່ດັ່ງກ່າວຕ້ອງການຫຼາຍກວ່າການລະບຸວ່າມີ RSC ຢູ່ຫຼືບໍ່. ທີມງານຂອງ Assetnote ໄດ້ເຜີຍແຜ່ ວິທີການກວດສອບທີ່ໜ້າເຊື່ອຖື ແລະ scanner ສາມາດຢືນຢັນບັນຫາໄດ້ໂດຍບໍ່ຕ້ອງໃຊ້ເຫດຜົນການຂຸດຄົ້ນໃດໆ. Metasploit ຈະມີໃນໄວໆນີ້ ການນຳໃຊ້ທີ່ມີປະໂຫຍດ ສຳລັບຊ່ອງໂຫວ່ນີ້ເຊັ່ນກັນ.
ວິທີການກວດສອບໃຊ້ປະໂຫຍດຈາກວິທີທີ່ React Server ຈັດການກັບການອ້າງອີງຄຸນສົມບັດຂອງວັດຖຸໂດຍໃຊ້ຕົວກຳນົດຈຸດສອງຈຸດພາຍໃນ ReactFlightClientConfigBundlerWebpack.js/requireModule() ໜ້າທີ່. ເມື່ອລຸ້ນທີ່ມີຄວາມສ່ຽງປະມວນຜົນ payload ຫຼາຍສ່ວນທີ່ມີໂຄງສ້າງພິເສດທີ່ພະຍາຍາມຂ້າມເສັ້ນທາງວັດຖຸທີ່ຊ້ອນກັນທີ່ບໍ່ມີຢູ່, ພວກມັນຈະກະຕຸ້ນການຕອບສະໜອງຄວາມຜິດພາດທີ່ຄາດເດົາໄດ້. ການຮ້ອງຂໍການວິນິດໄສສົ່ງຮູບແບບການອ້າງອີງເຊັ່ນ `$1:a:a` ຈັບຄູ່ກັບວັດຖຸຫວ່າງເປົ່າ. ການຈັດຕັ້ງປະຕິບັດທີ່ມີຄວາມສ່ຽງຕໍ່ການພະຍາຍາມແກ້ໄຂບັນຫານີ້ເປັນການເຂົ້າເຖິງຄຸນສົມບັດທີ່ຊ້ອນກັນໃນຄ່າທີ່ບໍ່ໄດ້ກຳນົດ, ເຊິ່ງເຮັດໃຫ້ເກີດຂໍ້ຍົກເວັ້ນ. ເຊີບເວີສົ່ງຄືນສະຖານະ 500 ດ້ວຍຮູບແບບການຍ່ອຍຄວາມຜິດພາດທີ່ໂດດເດັ່ນໃນເນື້ອຫາການຕອບສະໜອງ.
export function requireModule<T>(metadata: ClientReference<T>): T { let moduleExports = __webpack_require__(metadata[ID]); if (isAsyncImport(metadata)) { if (typeof moduleExports.then !== 'function') { // This wasn't a promise after all. } else if (moduleExports.status === 'fulfilled') { // This Promise should've been instrumented by preloadModule. moduleExports = moduleExports.value; } else { throw moduleExports.reason; } } if (metadata[NAME] === '*') { // This is a placeholder value that represents that the caller imported this // as a CommonJS module as is. return moduleExports; } if (metadata[NAME] === '') { // This is a placeholder value that represents that the caller accessed the // default property of this if it was an ESM interop module. return moduleExports.__esModule ? moduleExports.default : moduleExports; } return moduleExports[metadata[NAME]]; } ການປະຕິບັດທັນທີສຳລັບອົງກອນທີ່ປະເຊີນກັບ React2Shell (CVE-2025-55182) ແລະຄວາມສ່ຽງ RCE
ດຳເນີນການສະແກນຖານຂໍ້ມູນລະຫັດ ແລະ ແອັບພລິເຄຊັນທີ່ນຳໃຊ້ຢ່າງຄົບຖ້ວນ ເພື່ອຊອກຫາເວີຊັນແພັກເກດທີ່ມີຄວາມສ່ຽງ. ໃຫ້ເອົາໃຈໃສ່ເປັນພິເສດຕໍ່ການເພິ່ງພາອາໄສແພັກເກດເຊີບເວີ React ໂດຍກົງ, ການຈັດຕັ້ງປະຕິບັດ RSC ລະດັບ Framework (Next.js, Waku, Redwood, ແລະອື່ນໆ), ແອັບພລິເຄຊັນທີ່ສ້າງດ້ວຍ `create-next-app` ຫຼືເຄື່ອງມື scaffolding ທີ່ຄ້າຍຄືກັນ ແລະ ແອັບພລິເຄຊັນທີ່ມີ containerized ທີ່ອາດມີຮູບພາບພື້ນຖານທີ່ລ້າສະໄໝ.
ການວິເຄາະອົງປະກອບຊອບແວ (SCA) ເຄື່ອງມືເຊັ່ນ ຊີເຈນີ SCA ສາມາດຄົ້ນພົບການເພິ່ງພາອາໄສທີ່ໄດ້ຮັບຜົນກະທົບໂດຍອັດຕະໂນມັດຕະຫຼອດສາງຊອບແວຂອງທ່ານ.
ແກ້ໄຂທັນທີ:
ອັບເດດເປັນເວີຊັນທີ່ໄດ້ຮັບການແກ້ໄຂແລ້ວເຊັ່ນ: React (19.0.1, 19.1.2, 19.2.1), Next.js (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) ແລະແພັກເກດເຟຣມເວີກໃດໆທີ່ປະກອບມີ RSC. ການອັບເດດເຫຼົ່ານີ້ນຳສະເໜີການກວດສອບຄວາມຖືກຕ້ອງຢ່າງເຂັ້ມງວດສຳລັບການຈັດການ payload ຂອງ RSC ແລະປ້ອງກັນການຍົກເລີກຄຸນສົມບັດທີ່ບໍ່ປອດໄພທີ່ເຮັດໃຫ້ເກີດການຂູດຮີດ.
ເຄື່ອງມືແກ້ໄຂອັດຕະໂນມັດ, ເຊັ່ນ: ຄຸນສົມບັດການແກ້ໄຂອັດຕະໂນມັດຂອງ Xygeni, ສາມາດເລັ່ງຂະບວນການໃນທົ່ວຖານຂໍ້ມູນລະຫັດຂະໜາດໃຫຍ່ໄດ້.
ຈັດຕັ້ງປະຕິບັດການປົກປ້ອງ WAF ຊົ່ວຄາວ:
ໃນຂະນະທີ່ການແກ້ໄຂແຜ່ລາມຜ່ານການນຳໃຊ້ຂອງທ່ານ pipelineເປີດໃຊ້ກົດລະບຽບ Web Application Firewall ເພື່ອການປົກປ້ອງໃນທັນທີ. ຜູ້ໃຫ້ບໍລິການຄລາວລາຍໃຫຍ່ໄດ້ປ່ອຍຊຸດກົດລະບຽບສຸກເສີນແລ້ວ, CloudFlareການປົກປ້ອງອັດຕະໂນມັດສຳລັບທຸກຊັ້ນເມື່ອການຈະລາຈອນ React ຖືກ proxied ເຊັ່ນດຽວກັນກັບ AWS, Akamai, Fastly, Google Cloud ມີກົດລະບຽບປ້ອງກັນທີ່ຄ້າຍຄືກັນ ເປີດໃຊ້ການຄວບຄຸມເຫຼົ່ານີ້ທັນທີເພື່ອສ້າງຊັ້ນປ້ອງກັນໃນລະຫວ່າງໄລຍະເວລາການຫັນປ່ຽນ.
ຕິດຕາມກວດກາການຈະລາຈອນ HTTP ທີ່ໜ້າສົງໄສ:
ຕັ້ງຄ່າການບັນທຶກ ແລະ ການແຈ້ງເຕືອນສຳລັບຕົວຊີ້ວັດຂອງຄວາມພະຍາຍາມໃນການຂຸດຄົ້ນ: payload ຂອງໂປຣໂຕຄໍ RSC Flight ທີ່ມີຮູບແບບຜິດປົກກະຕິ ຫຼື ບໍ່ຄາດຄິດ, ຮູບແບບຜິດປົກກະຕິຂອງຄວາມຜິດພາດ 500 ຢ່າງໃນຈຸດສິ້ນສຸດ RSC, ການຮ້ອງຂໍ POST ທີ່ມີຫົວຂໍ້ `Next-Action` ຫຼື `Next-Router-State-Tree` ທີ່ໜ້າສົງໄສ, ການຮ້ອງຂໍຊ້ຳໆໄປຫາເສັ້ນທາງ `/_next/` ທີ່ມີ payload ຫຼາຍສ່ວນ.
ກວດສອບບັນຊີລາຍການຊອບແວຂອງທ່ານ:
ຫຼາຍໆເຟຣມເວີກລວມການເພິ່ງພາອາໄສ RSC ຢ່າງໂປ່ງໃສ, ເຮັດໃຫ້ພວກມັນເບິ່ງບໍ່ເຫັນໃນການທົບທວນການເພິ່ງພາອາໄສລະດັບພື້ນຜິວ. ກວດສອບຄວາມຄົບຖ້ວນຂອງທ່ານ SBOM ເພື່ອຮັບປະກັນ: ບໍ່ມີການເພິ່ງພາອາໄສແບບ transitive ໃນແພັກເກດເຊີບເວີ React ທີ່ມີຄວາມສ່ຽງ, ການອັບເດດ framework ບໍ່ໄດ້ນຳສະເໜີການປະຕິບັດ RSC ເກົ່າໂດຍບໍ່ໄດ້ຕັ້ງໃຈ.
Closing Thoughts
React2Shell ຖືກຈັດຢູ່ໃນບັນດາຊ່ອງໂຫວ່ລະບົບນິເວດ JavaScript ທີ່ຮ້າຍແຮງທີ່ສຸດໃນຊຸມປີມໍ່ໆມານີ້, ບໍ່ແມ່ນຍ້ອນວ່າຊ່ອງໂຫວ່ດັ່ງກ່າວມີຄວາມຊັບຊ້ອນ ແຕ່ຍ້ອນວ່າ RSC ດຳເນີນງານຢ່າງເລິກເຊິ່ງຜ່ານເຄື່ອງມືໃນປະຈຸບັນ. ໃນປັດຈຸບັນທີ່ການແກ້ໄຂມີໃຫ້ໃຊ້ທົ່ວລະບົບນິເວດ, ທີມງານຕ້ອງຍູ້ການຍົກລະດັບເຂົ້າສູ່ການຜະລິດໄວເທົ່າທີ່ຈະໄວໄດ້.
ຖ້າແອັບພລິເຄຊັນຂອງທ່ານໃຊ້ຄຸນສົມບັດເຊີບເວີຂອງ React, ບໍ່ວ່າຈະເປັນທາງກົງ ຫຼື ທາງອ້ອມ, ທ່ານຕ້ອງປະຕິບັດຕໍ່ຊ່ອງໂຫວ່ນີ້ເປັນການແກ້ໄຂທີ່ມີບູລິມະສິດສູງສຸດ.
