AI Found 300 WordPress Plugin Vulnerabilities in 72 Hours
AI നിമിഷങ്ങൾക്കുള്ളിൽ ബഗുകൾ കണ്ടെത്തുന്നു. ഇത് ഡെവലപ്പർമാരുടെ ലോകം തന്നെ മാറ്റുന്നു.
അടുത്തിടെ നടന്ന ഒരു സെക്യൂരിറ്റി സ്കാനിംഗിൽ വെറും 72 മണിക്കൂറിനുള്ളിൽ WordPress പ്ലഗിനുകളിൽ 300-ലധികം നിർണ്ണായകമായ zero-day സുരക്ഷാ വീഴ്ചകൾ കണ്ടെത്തി. ഗവേഷകർ ഇതിനെ "vibe coding" എന്ന് വിളിക്കുന്നു. ഡെവലപ്പർമാർ AI നിർമ്മിച്ച കോഡ് പരിശോധിക്കാതെ (auditing) നേരിട്ട് ഉപയോഗിക്കുമ്പോഴാണ് ഇത് സംഭവിക്കുന്നത്.
ഒരു ഏജൻസിക്ക് AI ഉപയോഗിച്ച് നിർമ്മിച്ച ഒരൊറ്റ പ്ലഗിനിൽ തന്നെ 100 സുരക്ഷാ പ്രശ്നങ്ങൾ കണ്ടെത്താൻ കഴിഞ്ഞു.
AI രണ്ട് വശത്തും പ്രവർത്തിക്കുന്നു. ഇത് വേഗത്തിൽ കോഡ് എഴുതുന്നുണ്ടെങ്കിലും, escaping, permission checks തുടങ്ങിയ സുരക്ഷാ നടപടികൾ പലപ്പോഴും ഒഴിവാക്കുന്നു. അതേസമയം, അറ്റാക്കർമാർ (attackers) ഇതേ സുരക്ഷാ വീഴ്ചകൾ പെട്ടെന്ന് കണ്ടെത്താൻ AI ഉപയോഗിക്കുന്നു.
പഴയ സുരക്ഷാ വലകൾ ഇല്ലാതായിരിക്കുന്നു. കോഡിന്റെ സങ്കീർണ്ണതയോ സമയമോ ഇനി നിങ്ങളുടെ കോഡിനെ സംരക്ഷിക്കില്ല. ഒരു ബഗ് പരസ്യമായാൽ ഏകദേശം അഞ്ച് മണിക്കൂറിനുള്ളിൽ തന്നെ വലിയ തോതിലുള്ള ചൂഷണങ്ങൾ (mass exploitation) നടക്കുന്നുണ്ടെന്ന് കണക്കുകൾ സൂചിപ്പിക്കുന്നു. പ്രതികരിക്കാൻ ഇതിലും കുറഞ്ഞ സമയം മതിയാവില്ല.
കഠിനമായ അനുഭവത്തിലൂടെയാണ് ഞാൻ ഇത് പഠിച്ചത്. ഞാൻ ഒരു AI chatbot പ്ലഗിൻ നിർമ്മിച്ചിരുന്നു. ഒരു സെക്യൂരിറ്റി റിവ്യൂവിൽ എന്റെ കോഡിൽ 35 ബഗുകൾ കണ്ടെത്തി. അതിൽ ഏറ്റവും മോശമായത് ഒരു HTML injection ആയിരുന്നു. ഞാൻ AI നൽകിയ ഔട്ട്പുട്ടിനെ വിശ്വസിച്ചു. AI ആണ് ഇത് എഴുതിയതെങ്കിൽ ഇത് സുരക്ഷിതമായിരിക്കുമെന്ന് ഞാൻ കരുതി.
അതൊരിക്കലും സുരക്ഷിതമായിരുന്നില്ല. ഉപയോക്താക്കളിൽ നിന്നോ ബാഹ്യ വെബ്സൈറ്റുകളിൽ നിന്നോ ഉള്ള ദോഷകരമായ ഉള്ളടക്കങ്ങൾ (malicious content) AI ഔട്ട്പുട്ടിൽ ഉണ്ടാകാൻ സാധ്യതയുണ്ട്. AI ഔട്ട്പുട്ടിനെ സുരക്ഷിതമായി കണക്കാക്കിയാൽ അത് സുരക്ഷാ വീഴ്ചയ്ക്ക് കാരണമാകും.
ഞാൻ എന്റെ പ്രവർത്തനരീതി (workflow) മാറ്റി. "ഇത് പ്രവർത്തിക്കുന്നുണ്ട്" എന്നതുകൊണ്ട് "ഇത് സുരക്ഷിതമാണ്" എന്ന് ഞാൻ ഇനി കരുതുന്നില്ല. ഇപ്പോൾ ഞാൻ AI എഴുതിയ ഓരോ ഹാൻഡ്ലറും (handler) മൂന്ന് കാര്യങ്ങളിൽ നേരിട്ട് പരിശോധിക്കുന്നു:
• Input: ഡാറ്റ എങ്ങനെ സിസ്റ്റത്തിലേക്ക് പ്രവേശിക്കുന്നു. • Output: ഡാറ്റ എങ്ങനെ സിസ്റ്റത്തിൽ നിന്ന് പുറത്തേക്ക് പോകുന്നു. AI മറുപടികളെ വിശ്വസിക്കാൻ കൊള്ളാത്ത ഇൻപുട്ടായി (untrusted input) ഞാൻ കണക്കാക്കുന്നു. ഞാൻ esc_html, wp_kses തുടങ്ങിയ ഫംഗ്ഷനുകൾ ഉപയോഗിക്കുന്നു. • Permissions: ഓരോ എൻട്രി പോയിന്റിലും യൂസർ കപ്പാബിലിറ്റികളും (user capabilities) nonces-ഉം ഞാൻ പരിശോധിക്കുന്നു.
യഥാർത്ഥ പ്രശ്നം കോഡ് മാത്രമല്ല, പ്രതികരണ സമയമാണ് (response time). ഒരു ബഗ് പരസ്യമാകുന്നതിന് മുൻപ് പല ഡെവലപ്പർമാരും അത് പരിഹരിക്കാനുള്ള പാച്ച് (patch) പുറത്തിറക്കാറില്ല. പല പ്ലഗിനുകളിലും പരിഹാരങ്ങൾ ഒട്ടുമില്ല.
നിങ്ങൾ ഒരു സോളോ ഡെവലപ്പർ ആണെങ്കിൽ, ശ്രദ്ധയോടെ കോഡ് എഴുതിയിട്ട് എല്ലാം ശരിയാകുമെന്ന് പ്രതീക്ഷിച്ചിട്ട് കാര്യമില്ല. ബഗുകൾ പരസ്യമാകുന്നതിന് മുൻപ് ആളുകൾക്ക് നിങ്ങളെ അറിയിക്കാൻ ഒരു മാർഗ്ഗം ആവശ്യമാണ്.
2026 അവസാനത്തോടെ, സുരക്ഷാ വീഴ്ചകൾ വെളിപ്പെടുത്തുന്നതിനുള്ള പ്രോഗ്രാമുകൾ (vulnerability disclosure programs) നിർബന്ധമാക്കുമെന്ന് EU നിയമങ്ങൾ പറയുന്നു. സോളോ ഓതർമാർക്ക് ഇത് ലളിതമായി ചെയ്യാവുന്നതാണ്. നിങ്ങളുടെ readme ഫയലിൽ ഒരു സെക്യൂരിറ്റി കോൺടാക്റ്റ് ചേർക്കുക. റിപ്പോർട്ടുകൾ അയക്കാൻ ആളുകൾക്ക് ഒരു സ്വകാര്യ ഇടം നൽകുക.
ഒരു പബ്ലിക് എക്സ്പ്ലോയിറ്റിനായി (public exploit) കാത്തുനിൽക്കരുത്. അഞ്ച് മണിക്കൂർ സമയപരിധി തുടങ്ങുന്നതിന് മുൻപ് തന്നെ ബഗുകൾ കണ്ടെത്താനുള്ള സംവിധാനങ്ങൾ ഒരുക്കുക.
Optional learning community: https://t.me/GyaanSetuAi