better-auth قبل 1.7.7: إيميل المستخدم بيكفي ليدخل مهاجم على حسابه

إذا مشروعك بيستعمل better-auth مع تسجيل دخول برابط بالإيميل (Magic Link) وتسجيل دخول اجتماعي أو أي مزوّد OAuth، فمهاجم بيعرف إيميل مستخدم عندك كان بيقدر يفتح جلسة بحسابه. هون بتعرف إذا إعداداتك متأثرة، وكيف تصلّحها اليوم.

شو الثغرة بـ better-auth؟

الثغرة هي إنو better-auth كانت تقبل قيمة state تبع تسجيل دخول OAuth كأنها رمز Magic Link. وإرشادها بقاعدة ثغرات GitHub بيسجّلها باسم CVE-2026-114607، وبيقيّمها حرجة، 9.1 على CVSS 3.1.

الـ state هي القيمة يلي بتربط بداية تسجيل دخول OAuth برجعته. ورمز Magic Link هو الرمز يلي بيوصل بالإيميل وبيفتح الجلسة. يعني المكتبة كانت تقبل قيمة بيقدر أي حدا يطلبها، مكان رمز لازم يوصل لصندوق بريد صاحب الحساب بس.

الإرشاد الأصلي انتشر بريبو better-auth بـ 30 أيلول 2026، والإصلاح نزل بـ 1.7.7. وبـ 27 تشرين الأول 2026 انضاف الإرشاد GHSA-965c-763c-88jm لقاعدة ثغرات GitHub بعد المراجعة.

كيف بيدخل المهاجم بإيميل بس؟

المهاجم ما بيحتاج صندوق البريد، ولا حساب عند مزوّد OAuth، ولا يكمّل رجعة OAuth. حسب الإرشاد، الهجوم بيمشي هيك:

1. بيبلّش تسجيل دخول OAuth لأي عنوان إيميل بدّه ياه.

2. بياخد قيمة الـ state يلي رجعت.

3. بيستعملها ليكمّل تسجيل دخول Magic Link لنفس العنوان، فبياخد جلسة عادية بصلاحيات هالحساب.

وإذا التسجيل بـ Magic Link مفتوح وما في حساب للعنوان، المهاجم بيعمل حساب جديد معلّم إنو إيميله موثّق وهو مش موثّق. والإرشاد بيقول إنو هالعلامة الغلط ممكن تتجاوز حمايات المكتبة للحسابات غير المثبتة لما صاحب الإيميل الحقيقي بيسجّل دخول بعدين.

هل مشروعي متأثر؟

مشروعك متأثر إذا نسختك من 1.4.0-beta.18 لحد النسخ يلي قبل 1.7.7، والتلات شروط هدول كلهن صح:

1. Magic Link شغّال مع storeToken: "plain" الافتراضي، أو مع storeToken: "hashed" وverification.storeIdentifier: "hashed" العام.

2. في مزوّد تسجيل دخول اجتماعي مدمج واحد على الأقل، أو مزوّد Generic OAuth.

3. الـ state تبع OAuth متخزنة بقاعدة البيانات (account.storeStateStrategy: "database")، وهاد الافتراضي لما يكون في قاعدة بيانات أو تخزين ثانوي.

يعني إعداد بسيط: قاعدة بيانات، وMagic Link، وزر تسجيل دخول اجتماعي. وإذا قصة التوكنات المزوّرة بتهمك، كتبنا قبل عن ثغرة Postiz يلي بتخلّي مستخدم يسرق منظمة كاملة.

كيف بتصلّحها؟

حدّث better-auth لـ 1.7.7، وحدّث معها الـ adapters والإضافات وكل التكاملات بنفس الوقت. ملاحظات الإصدار بتقول إنو النسخة صلّحت ثغرة استيلاء حرجة بـ Magic Link.

انتبه لهالنقاط من الإرشاد قبل ما تنشر التحديث:

• إذا عندك كذا سيرفر بيتشاركوا نفس تخزين التحقق، حدّثهن كلهن بنفس النقلة.

• روابط Magic Link وحالات OAuth وSAML يلي انعملت قبل التحديث ما بتكمل، فالمستخدم بيطلب رابط جديد.

• إذا عندك قواعد خاصة بـ verification.storeIdentifier.overrides، عدّلها لتطابق البادئتين magic-link: وauth-state:.

• ما في ترحيل لبيانات المستخدمين أو الحسابات.

وإذا مشروعك مبني على Next.js، شوف كمان تحديث Next.js الأمني يلي كتبنا عنه إذا لسا ما حدّثت.

شو تعمل إذا ما فيك تحدّث هلق؟

الإرشاد بيعطي تلات حلول مؤقتة لحد ما تحدّث:

1. خلّي الـ state بالكوكي بدل قاعدة البيانات. وإذا بتستعمل OAuth Proxy، اضبط أول شي سر خاص فيه بكل البيئات، مختلف عن السر العام لكل بيئة.

2. خلّي storeToken تبع Magic Link على "hashed"، واترك verification.storeIdentifier العام فاضي أو على "plain".

3. وقّف تسجيل الدخول بـ Magic Link، أو وقّف تسجيل الدخول الاجتماعي وGeneric OAuth.

export const auth = betterAuth({
  account: {
    storeStateStrategy: "cookie",
  },
});

وdisableSignUp: true على إضافة Magic Link ما بيكفي: بيمنع حسابات جديدة بس، وما بيمنع الاستيلاء على حساب موجود.

من وين تبلّش هلق؟

بلّش بالنسخة والإعدادات، لأنو هنن يلي بيقرروا إذا مشروعك معرّض أصلاً.

1. شغّل npm ls better-auth وشوف نسختك.

2. افتح إعدادات betterAuth وشيّك التلات شروط فوق.

3. حدّث لـ 1.7.7 مع كل الإضافات، أو طبّق حل مؤقت اليوم وحدّث بعدين.

4. قول لمستخدميك إنو روابط تسجيل الدخول القديمة ما عادت بتشتغل.

وإذا بدك حدا يجرّب مسار تسجيل الدخول بمنصتك متل ما بيجرّبه مهاجم، هاد شغل مُحَصَّن.

ومقالات أمان التطبيقات كلها بمكان واحد: أمن التطبيقات.