InvoiceShelf, ఒక కంపెనీలోని ఏ ఓనర్ అయినా మరో కంపెనీలోని యూజర్ ఖాతాలను హైజాక్ చేయడానికి వీలు కల్పించే CVE-2026-55610 అనే క్లిష్టమైన లోపం (critical flaw) కోసం ఒక ప్యాచ్‌ను విడుదల చేసింది. CVSS స్కేల్‌లో 8.7 రేటింగ్ పొందిన ఈ లోపం, యాప్‌లోని Laravel కోడ్‌లో టెనెంట్-స్కోప్ (tenant-scope) చెక్ లేకపోవడం వల్ల ఏర్పడింది.

ఈ లోపం ఎలా పనిచేసింది

InvoiceShelf అనేది Laravel పై ఆధారపడి రూపొందించబడిన ఒక SaaS టూల్, ఇది కంపెనీలు తమ యూజర్లు, ఇన్వాయిస్‌లు మరియు సెట్టింగ్‌లను ఒకే డ్యాష్‌బోర్డ్ నుండి నిర్వహించడానికి అనుమతిస్తుంది. ఈ ప్లాట్‌ఫారమ్ టెనెంట్‌ను గుర్తించడానికి ఒక కస్టమ్ హెడర్‌ను చదువుతుంది. ఒక ఓనర్ యూజర్ రికార్డును కోరినప్పుడు, కోడ్ కేవలం, “కోరే వ్యక్తి తన స్వంత కంపెనీకి ఓనరా?” అని మాత్రమే తనిఖీ చేస్తుంది.

టార్గెట్ యూజర్ అదే టెనెంట్‌కు చెందినవారో కాదో ఇది ఎప్పుడూ ధృవీకరించదు. Laravel యొక్క implicit route-model binding, యూజర్ IDని గ్లోబల్ యూజర్స్ టేబుల్‌లోని ఒక రో (row)గా మారుస్తుంది, మరియు అథరైజేషన్ పాలసీ కేవలం కోరే వ్యక్తి యొక్క రోల్ (role) ఆధారంగా మాత్రమే రిక్వెస్ట్‌ను ఆమోదిస్తుంది.

దీనివల్ల ఒక అటాకర్:

  • రిక్వెస్ట్ URLలో ఏదైనా నంబరిక్ యూజర్ IDని అందించవచ్చు.
  • ఈమెయిల్ సహా పూర్తి యూజర్ రికార్డును పొందవచ్చు.
  • బాధితుడి ఈమెయిల్, పాస్‌వర్డ్‌ను ఓవర్‌రైట్ చేస్తూ అప్‌డేట్ చేయవచ్చు మరియు ఆ ఖాతాను సూపర్-అడ్మిన్‌గా అటాకర్ యొక్క కంపెనీకి తిరిగి కేటాయించవచ్చు.

వాస్తవానికి, ఒక దుర్మార్గపు ఓనర్ కంపెనీ-మేనేజ్‌మెంట్ టూల్‌ను యూనివర్సల్ అకౌంట్-టేకోవర్ ఆయుధంగా మార్చగలిగారు. దీని కోసం “Owner” కంటే ఎక్కువ అధికారాలు అవసరం లేదు.

ఎవరు ప్రభావితమవుతారు

2.4.1 కంటే ముందు వెర్షన్‌ను ఉపయోగిస్తున్న ప్రతి InvoiceShelf కస్టమర్ కూడా దీనికి గురయ్యారు. ఈ లోపం కోర్ రిక్వెస్ట్-హ్యాండ్లింగ్ పాత్‌లో ఉండటం వల్ల, కంపెనీ పరిమాణం లేదా భద్రతా స్థితితో సంబంధం లేకుండా, ఏ టెనెంట్‌నైనా మరొక టెనెంట్ ఓనర్ లక్ష్యంగా చేసుకోవచ్చు. దీని ప్రభావంలో గోప్యత కోల్పోవడం (ఈమెయిల్ అడ్రస్‌లు) మరియు సమగ్రత కోల్పోవడం (అనధికారిక పాస్‌వర్డ్ మార్పులు, సూపర్-అడ్మిన్‌గా స్థాయి పెరగడం) వంటివి ఉన్నాయి.

ప్యాచ్

డెవలపర్లు వెర్షన్ 2.4.1ని విడుదల చేశారు, ఇది యూజర్ రికార్డుపై ఏదైనా రీడ్ లేదా రైట్ ఆపరేషన్ చేయడానికి ముందు స్పష్టమైన టెనెంట్ చెక్‌ను జోడించింది. ఈ ఫిక్స్ క్వెరీని యాక్టివ్ కంపెనీ ఐడెంటిఫైయర్‌కు పరిమితం చేస్తుంది, తద్వారా Laravel కేవలం కోరే వ్యక్తి యొక్క టెనెంట్‌కు చెందిన రోలను మాత్రమే తిరిగి ఇచ్చేలా చేస్తుంది.

డెవలపర్లు ఏమి నేర్చుకోవాలి

  • మల్టీ-టెనెంట్ అప్లికేషన్లలో ఎప్పుడూ గ్లోబల్ ప్రైమరీ కీలపై ఆధారపడకండి.
  • కేవలం డిలీట్ లేదా క్రియేట్ చర్యలకు మాత్రమే కాకుండా, ప్రతి డేటాబేస్ లుకప్‌కు టెనెంట్ ఫిల్టర్‌ను వర్తింపజేయండి.
  • అథరైజేషన్ పాలసీలు చేసే వ్యక్తి యొక్క రోల్ మరియు టార్గెట్ ఆబ్జెక్ట్ యొక్క టెనన్సీ (tenancy) రెండింటినీ ధృవీకరించేలా చేయండి.
  • రూట్-మోడల్ బైండింగ్ వంటి ఇంప్లిసిట్ ఫ్రేమ్‌వర్క్ ఫీచర్లను కేవలం సౌకర్యాలుగా మాత్రమే చూడండి; మీరు స్పష్టమైన స్కోపింగ్‌ను జోడించకపోతే అవి భద్రతా లోపాలను దాచవచ్చు.

భవిష్యత్తును దృష్టిలో ఉంచుకుని

టేబుల్స్‌ను పంచుకునే ఏ SaaSకైనా ఈ సంఘటన ఒక విస్తృతమైన ప్రమాదాన్ని చూపుతుంది. ఐడెంటిఫైయర్‌లను స్వీకరించే అన్ని ఎండ్‌పాయింట్‌లను సెక్యూరిటీ ఆడిట్‌లు సమీక్షించాలి మరియు టెనెంట్ స్కోపింగ్ ఏకరీతిగా అమలు చేయబడిందని నిర్ధారించుకోవాలి.

ముఖ్య గమనిక: ఒకే ఒక్క టెనెంట్ చెక్ లేకపోవడం వల్ల అధికారం ఉన్న యూజర్ రోల్ ఒక యూనివర్సల్ బ్యాక్‌డోర్‌గా మారవచ్చు. సరైన స్కోపింగ్ అనేది ఐచ్ఛికం కాదు; ఇది ఏ మల్టీ-టెనెంట్ సిస్టమ్‌లోనైనా డేటా ఐసోలేషన్‌కు పునాది.