InvoiceShelf ਨੇ CVE-2026-55610 ਲਈ ਇੱਕ ਪੈਚ ਜਾਰੀ ਕੀਤਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਗੰਭੀਰ ਖਾਮੀ ਹੈ ਜਿਸ ਨਾਲ ਇੱਕ ਕੰਪਨੀ ਦਾ ਕੋਈ ਵੀ ਮਾਲਕ ਦੂਜੀ ਕੰਪਨੀ ਦੇ ਯੂਜ਼ਰ ਅਕਾਊਂਟਾਂ ਨੂੰ ਹਾਈਜੈਕ ਕਰ ਸਕਦਾ ਸੀ। CVSS ਸਕੇਲ 'ਤੇ 8.7 ਰੇਟ ਕੀਤੀ ਗਈ ਇਹ ਕਮਜ਼ੋਰੀ, ਐਪ ਦੇ Laravel ਕੋਡ ਵਿੱਚ ਟੈਨੈਂਟ-ਸਕੋਪ ਚੈੱਕ (tenant-scope check) ਦੀ ਘਾਟ ਕਾਰਨ ਪੈਦਾ ਹੋਈ ਸੀ।

ਇਹ ਖਾਮੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਸੀ

InvoiceShelf ਇੱਕ Laravel 'ਤੇ ਬਣਿਆ SaaS ਟੂਲ ਹੈ ਜੋ ਕੰਪਨੀਆਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਯੂਜ਼ਰਸ, ਇਨਵੌਇਸ ਅਤੇ ਸੈਟਿੰਗਾਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਲੇਟਫਾਰਮ ਟੈਨੈਂਟ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਇੱਕ ਕਸਟਮ ਹੈਡਰ (custom header) ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਮਾਲਕ (Owner) ਯੂਜ਼ਰ ਰਿਕਾਰਡ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੋਡ ਸਿਰਫ਼ ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ, "ਕੀ ਬੇਨਤੀ ਕਰਨ ਵਾਲਾ ਆਪਣੀ ਕੰਪਨੀ ਦਾ ਮਾਲਕ ਹੈ?"

ਇਹ ਕਦੇ ਵੀ ਇਹ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ ਕਿ ਟਾਰਗੇਟ ਯੂਜ਼ਰ ਉਸੇ ਟੈਨੈਂਟ ਨਾਲ ਸਬੰਧਤ ਹੈ। Laravel ਦੀ ਇੰਪਲੀਸਿਟ ਰੂਟ-ਮਾਡਲ ਬਾਈਂਡਿੰਗ (implicit route-model binding) ਯੂਜ਼ਰ ID ਨੂੰ ਗਲੋਬਲ ਯੂਜ਼ਰਸ ਟੇਬਲ ਦੀ ਇੱਕ ਰੋਅ (row) ਨਾਲ ਜੋੜ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਪਾਲਿਸੀ ਸਿਰਫ਼ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਦੇ ਰੋਲ ਦੇ ਅਧਾਰ 'ਤੇ ਬੇਨਤੀ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੰਦੀ ਹੈ।

ਇੱਕ ਅਟੈਕਰ ਇਸ ਤਰ੍ਹਾਂ ਕਰ ਸਕਦਾ ਸੀ:

  • ਬੇਨਤੀ URL ਵਿੱਚ ਕੋਈ ਵੀ ਨੰਬਰ ਵਾਲੀ ਯੂਜ਼ਰ ID ਭੇਜ ਸਕਦਾ ਹੈ।
  • ਈਮੇਲ ਸਮੇਤ ਪੂਰਾ ਯੂਜ਼ਰ ਰਿਕਾਰਡ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।
  • ਇੱਕ ਅਪਡੇਟ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਪੀੜਤ ਦੀ ਈਮੇਲ, ਪਾਸਵਰਡ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਅਕਾਊਂਟ ਨੂੰ ਅਟੈਕਰ ਦੀ ਕੰਪਨੀ ਵਿੱਚ ਸੁਪਰ-ਐਡਮਿਨ (super-admin) ਵਜੋਂ ਮੁੜ ਨਿਯੁਕਤ ਕਰ ਦਿੰਦਾ ਹੈ।

ਅਸਲ ਵਿੱਚ, ਇੱਕ ਮਾੜੇ ਮਨ ਵਾਲੇ ਮਾਲਕ ਨੇ ਕੰਪਨੀ-ਪ੍ਰਬੰਧਨ ਟੂਲ ਨੂੰ ਯੂਨੀਵਰਸਲ ਅਕਾਊਂਟ-ਟੇਕਓਵਰ ਹਥਿਆਰ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਇਸ ਲਈ "Owner" ਤੋਂ ਵੱਧ ਕਿਸੇ ਹੋਰ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।

ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੈ

2.4.1 ਤੋਂ ਪਹਿਲਾਂ ਵਾਲਾ ਵਰਜ਼ਨ ਚਲਾਉਣ ਵਾਲਾ ਹਰ InvoiceShelf ਗਾਹਕ ਇਸ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਸੀ। ਕਿਉਂਕਿ ਇਹ ਖਾਮੀ ਕੋਰ ਰਿਕਵੈਸਟ-ਹੈਂਡਲਿੰਗ ਪਾਥ (core request-handling path) ਵਿੱਚ ਹੈ, ਇਸ ਲਈ ਆਕਾਰ ਜਾਂ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਕਿਸੇ ਵੀ ਟੈਨੈਂਟ ਨੂੰ ਕਿਸੇ ਦੂਜੇ ਟੈਨੈਂਟ ਦੇ ਮਾਲਕ ਦੁਆਰਾ ਨਿਸ਼ਾਨਾ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਸੀ। ਇਸ ਦੇ ਪ੍ਰਭਾਵਾਂ ਵਿੱਚ ਗੁਪਤਤਾ ਦੀ ਕਮੀ (ਈਮੇਲ ਪਤੇ) ਅਤੇ ਅਖੰਡਤਾ ਦੀ ਕਮੀ (ਅਣਅਧਿਕਾਰਤ ਪਾਸਵਰਡ ਤਬਦੀਲੀਆਂ, ਸੁਪਰ-ਐਡਮਿਨ ਵਜੋਂ ਅਧਿਕਾਰ ਵਧਾਉਣਾ) ਸ਼ਾਮਲ ਹਨ।

ਪੈਚ (The Patch)

ਡਿਵੈਲਪਰਾਂ ਨੇ ਵਰਜ਼ਨ 2.4.1 ਜਾਰੀ ਕੀਤਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ ਰਿਕਾਰਡ 'ਤੇ ਕਿਸੇ ਵੀ ਰੀਡ ਜਾਂ ਰਾਈਟ ਆਪਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਟੈਨੈਂਟ ਚੈੱਕ ਜੋੜਿਆ ਗਿਆ ਹੈ। ਇਹ ਫਿਕਸ ਕੁਐਰੀ (query) ਨੂੰ ਸਰਗਰਮ ਕੰਪਨੀ ਆਈਡੈਂਟੀਫਾਇਰ ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ Laravel ਸਿਰਫ਼ ਉਹਨਾਂ ਰੋਅਜ਼ (rows) ਨੂੰ ਵਾਪਸ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੁੰਦਾ ਹੈ ਜੋ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਦੇ ਟੈਨੈਂਟ ਨਾਲ ਸਬੰਧਤ ਹਨ।

ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੀ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ

  • ਮਲਟੀ-ਟੈਨੈਂਟ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਕਦੇ ਵੀ ਗਲੋਬਲ ਪ੍ਰਾਇਮਰੀ ਕੀਜ਼ (global primary keys) 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ।
  • ਹਰ ਡੇਟਾਬੇਸ ਲੁੱਕਅੱਪ 'ਤੇ ਟੈਨੈਂਟ ਫਿਲਟਰ ਲਾਗੂ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਡਿਲੀਟ ਜਾਂ ਕ੍ਰਿਏਟ ਐਕਸ਼ਨਾਂ 'ਤੇ।
  • ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਪਾਲਿਸੀਆਂ ਨੂੰ ਐਕਟਰ ਦੇ ਰੋਲ ਅਤੇ ਟਾਰਗੇਟ ਆਬਜੈਕਟ ਦੀ ਟੈਨੈਂਸੀ (tenancy) ਦੋਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਬਣਾਓ।
  • ਰੂਟ-ਮਾਡਲ ਬਾਈਂਡਿੰਗ ਵਰਗੀਆਂ ਇੰਪਲੀਸਿਟ ਫਰੇਮਵਰਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਹੂਲਤਾਂ ਵਜੋਂ ਲਓ ਜੋ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਨੂੰ ਛੁਪਾ ਸਕਦੀਆਂ ਹਨ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਸਕੋਪਿੰਗ (explicit scoping) ਨਹੀਂ ਜੋੜਦੇ।

ਅੱਗੇ ਵੱਲ ਦੇਖਦੇ ਹੋਏ

ਇਹ ਘਟਨਾ ਕਿਸੇ ਵੀ SaaS ਲਈ ਇੱਕ ਵਿਆਪਕ ਜੋਖਮ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਟੇਬਲ ਸਾਂਝੇ ਕਰਦੇ ਹਨ। ਸੁਰੱਖਿਆ ਆਡਿਟਸ ਨੂੰ ਉਹਨਾਂ ਸਾਰੇ ਐਂਡਪੁਆਇੰਟਸ (endpoints) ਦੀ ਸਮੀਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਆਈਡੈਂਟੀਫਾਇਰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਟੈਨੈਂਟ ਸਕੋਪਿੰਗ ਨੂੰ ਇੱਕਸਾਰ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਸਿੱਖਿਆ (Takeaway): ਇੱਕ ਗਲਤ ਟੈਨੈਂਟ ਚੈੱਕ ਇੱਕ ਅਧਿਕਾਰਤ ਯੂਜ਼ਰ ਰੋਲ ਨੂੰ ਯੂਨੀਵਰਸਲ ਬੈਕਡੋਰ (backdoor) ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। ਸਹੀ ਸਕੋਪਿੰਗ ਵਿਕਲਪਿਕ ਨਹੀਂ ਹੈ; ਇਹ ਕਿਸੇ ਵੀ ਮਲਟੀ-ਟੈਨੈਂਟ ਸਿਸਟਮ ਵਿੱਚ ਡੇਟਾ ਆਇਸੋਲੇਸ਼ਨ (data isolation) ਦੀ ਨੀਂਹ ਹੈ।