⚠️ YellowKey: вразливість, яка ставить під сумнів надійність BitLocker ⚠️
Дослідник безпеки під псевдонімом *Nightmare-Eclipse* опублікував PoC-експлойт для нової вразливості YellowKey (CVE-2026-45585), яка дозволяє обійти захист BitLocker у Windows 11 та Windows Server 2025. (Microsoft provides mitigation for "YellowKey" BitLocker bypass flaw (CVE-2026-45585) - Help Net Security)
📌 Що це таке?
YellowKey — це не класичне «зламування шифрування».
Вразливість використовує особливості роботи Windows Recovery Environment (WinRE) та механізму автоматичного розблокування диска через TPM.
Для атаки достатньо:
• фізичного доступу до пристрою;
• USB-накопичувача зі спеціальною структурою файлів (
• перезавантаження системи у режим відновлення.
Після цього зловмисник може отримати командний рядок із доступом до вже розшифрованого диска — без введення ключа BitLocker або пароля користувача. (YellowKey: BitLocker Bypass Discovered in Windows 11 | Blackfort Technology)
💡 Особливість атаки в тому, що BitLocker сам розблоковує диск через TPM під час завантаження, а WinRE у певних сценаріях зберігає цей доступ.
🔍 Чому це настільки серйозно?
BitLocker використовується:
• у корпоративному секторі;
• державних установах;
• ноутбуках із Windows 11 за замовчуванням;
• серверах Windows.
Фактично YellowKey означає, що викрадений ноутбук із TPM-only BitLocker може бути прочитаний за лічені хвилини. (Windows BitLocker "YellowKey" + CTFMON "GreenPlasma" — public PoC, no patch, TPM-only BitLocker bypassed)
Дослідник навіть заявив, що механізм виглядає настільки дивно, ніби це «навмисно залишений бекдор», хоча доказів цього немає. Ці слова викликали гучні дискусії у спільноті кібербезпеки. (A security researcher says Microsoft secretly built a backdoor into BitLocker, releases an exploit to prove it | TechSpot)
🛠 Що зробила Microsoft?
Microsoft офіційно підтвердила проблему та випустила тимчасові заходи захисту, поки готується повноцінний патч. (Microsoft provides mitigation for "YellowKey" BitLocker bypass flaw (CVE-2026-45585) - Help Net Security)
Основні рекомендації:
✅ відмовитися від режиму TPM-only;
✅ увімкнути TPM + PIN для BitLocker;
✅ змінити конфігурацію WinRE;
✅ посилити фізичний захист пристроїв.
На момент публікації повноцінне оновлення безпеки ще готується. (Microsoft provides mitigation for "YellowKey" BitLocker bypass flaw (CVE-2026-45585) - Help Net Security)
⚠️ Важливий момент:
YellowKey НЕ дозволяє віддалений злам через інтернет.
Атака потребує фізичного доступу до пристрою.
Але для журналістів, активістів, військових, держслужбовців та всіх, хто ризикує втратити ноутбук чи ПК, це дуже серйозна проблема.
🔐 Якщо ви використовуєте BitLocker — режим TPM+PIN тепер фактично стає обов’язковим, а не «додатковою опцією».
#yellowkey #безпека #bitlocker #microsoft #windows #вразливість
Дослідник безпеки під псевдонімом *Nightmare-Eclipse* опублікував PoC-експлойт для нової вразливості YellowKey (CVE-2026-45585), яка дозволяє обійти захист BitLocker у Windows 11 та Windows Server 2025. (Microsoft provides mitigation for "YellowKey" BitLocker bypass flaw (CVE-2026-45585) - Help Net Security)
📌 Що це таке?
YellowKey — це не класичне «зламування шифрування».
Вразливість використовує особливості роботи Windows Recovery Environment (WinRE) та механізму автоматичного розблокування диска через TPM.
Для атаки достатньо:
• фізичного доступу до пристрою;
• USB-накопичувача зі спеціальною структурою файлів (
FsTx);• перезавантаження системи у режим відновлення.
Після цього зловмисник може отримати командний рядок із доступом до вже розшифрованого диска — без введення ключа BitLocker або пароля користувача. (YellowKey: BitLocker Bypass Discovered in Windows 11 | Blackfort Technology)
💡 Особливість атаки в тому, що BitLocker сам розблоковує диск через TPM під час завантаження, а WinRE у певних сценаріях зберігає цей доступ.
🔍 Чому це настільки серйозно?
BitLocker використовується:
• у корпоративному секторі;
• державних установах;
• ноутбуках із Windows 11 за замовчуванням;
• серверах Windows.
Фактично YellowKey означає, що викрадений ноутбук із TPM-only BitLocker може бути прочитаний за лічені хвилини. (Windows BitLocker "YellowKey" + CTFMON "GreenPlasma" — public PoC, no patch, TPM-only BitLocker bypassed)
Дослідник навіть заявив, що механізм виглядає настільки дивно, ніби це «навмисно залишений бекдор», хоча доказів цього немає. Ці слова викликали гучні дискусії у спільноті кібербезпеки. (A security researcher says Microsoft secretly built a backdoor into BitLocker, releases an exploit to prove it | TechSpot)
🛠 Що зробила Microsoft?
Microsoft офіційно підтвердила проблему та випустила тимчасові заходи захисту, поки готується повноцінний патч. (Microsoft provides mitigation for "YellowKey" BitLocker bypass flaw (CVE-2026-45585) - Help Net Security)
Основні рекомендації:
✅ відмовитися від режиму TPM-only;
✅ увімкнути TPM + PIN для BitLocker;
✅ змінити конфігурацію WinRE;
✅ посилити фізичний захист пристроїв.
На момент публікації повноцінне оновлення безпеки ще готується. (Microsoft provides mitigation for "YellowKey" BitLocker bypass flaw (CVE-2026-45585) - Help Net Security)
⚠️ Важливий момент:
YellowKey НЕ дозволяє віддалений злам через інтернет.
Атака потребує фізичного доступу до пристрою.
Але для журналістів, активістів, військових, держслужбовців та всіх, хто ризикує втратити ноутбук чи ПК, це дуже серйозна проблема.
🔐 Якщо ви використовуєте BitLocker — режим TPM+PIN тепер фактично стає обов’язковим, а не «додатковою опцією».
#yellowkey #безпека #bitlocker #microsoft #windows #вразливість
Help Net Security
Microsoft provides mitigation for “YellowKey” BitLocker bypass flaw (CVE-2026-45585)
Microsoft is working on a fix for CVE-2026-45585 (aka "Yellowkey"), a vulnerability that can be used to bypass Windows' BitLocker protection.
❤1👍1🔥1
🧟 Zombie ZIP: 20-річна вразливість, яка знову дозволяє обходити антивіруси
Дослідники з компанії Bombadil Systems привернули увагу до старої вразливості ZIP-архівів — CVE-2004-0935, яка отримала нове життя під назвою «Zombie ZIP». Її суть проста: антивірус довіряє заголовку ZIP-файлу більше, ніж реальному вмісту архіву. ('Zombie ZIP’ slips malware past 98% of antivirus engines | news | SC Media)
📦 Як працює атака?
ZIP-архів містить службові поля (headers), де вказано метод стиснення файлів. Зловмисник навмисно підробляє ці поля:
• у заголовку вказується, що файл НЕ стиснений (метод STORED / 0);
• але фактично дані всередині стиснені методом DEFLATE (8);
• антивірус бачить лише набір «випадкових байтів» і не розпаковує payload для перевірки;
• спеціальний loader вже на стороні жертви правильно витягує та запускає шкідливий код. (Zombie ZIP Vulnerability: WinRAR and 7-Zip Bypass All 50 Antivirus Engines)
Через додаткову невідповідність CRC та службових полів стандартні архіватори часто вважають такий ZIP «пошкодженим». Але це не заважає спеціально написаному завантажувачу отримати payload. (‘Zombie ZIP’ slips malware past 98% of antivirus engines | news | SC Media)
👨💻 Автор дослідження — Chris Aziz із Bombadil Systems. Він опублікував proof-of-concept код, який демонструє створення таких архівів:
Zombie ZIP PoC (loader_poc.py)
⚠️ Чому це небезпечно?
Проблема не лише у ZIP-файлах. Багато антивірусів, поштових шлюзів та sandbox-систем покладаються на «швидкий аналіз» архівів без повної перевірки структури. Це відкриває можливість:
• доставляти malware через email-вкладення;
• обходити корпоративні системи фільтрації;
• приховувати payload від автоматичного аналізу;
• використовувати ZIP як контейнер для подальшого stage-loader зараження. (Zombie ZIP method can fool antivirus during the first scan - Security Boulevard)
📊 Найгірше — рівень виявлення.
За результатами тестів Chris Aziz:
• лише 1 із 51 антивірусів на VirusTotal виявив загрозу;
• інші пропустили архів як «безпечний»;
• окремі джерела повідомляють про 60 із 63 AV-движків, що не змогли детектувати атаку (~95%). (‘Zombie ZIP’ slips malware past 98% of antivirus engines | news | SC Media)
Фактично це означає, що багато сучасних систем захисту все ще довіряють метаданим архіву більше, ніж його реальному вмісту — проблема, відома ще з 2004 року. (CVE-2004-0935 Security Vulnerability & Exploit Details)
🛡 Висновок:
Антивірус — це лише один із рівнів захисту. Якщо користувач запускає невідомі loader’и, «patcher.exe», «viewer.exe» або інші допоміжні файли з архіву — жоден ZIP-фільтр не врятує.
А «пошкоджений архів», який «чомусь не відкривається», може бути не помилкою, а частиною атаки.
Дослідники з компанії Bombadil Systems привернули увагу до старої вразливості ZIP-архівів — CVE-2004-0935, яка отримала нове життя під назвою «Zombie ZIP». Її суть проста: антивірус довіряє заголовку ZIP-файлу більше, ніж реальному вмісту архіву. ('Zombie ZIP’ slips malware past 98% of antivirus engines | news | SC Media)
📦 Як працює атака?
ZIP-архів містить службові поля (headers), де вказано метод стиснення файлів. Зловмисник навмисно підробляє ці поля:
• у заголовку вказується, що файл НЕ стиснений (метод STORED / 0);
• але фактично дані всередині стиснені методом DEFLATE (8);
• антивірус бачить лише набір «випадкових байтів» і не розпаковує payload для перевірки;
• спеціальний loader вже на стороні жертви правильно витягує та запускає шкідливий код. (Zombie ZIP Vulnerability: WinRAR and 7-Zip Bypass All 50 Antivirus Engines)
Через додаткову невідповідність CRC та службових полів стандартні архіватори часто вважають такий ZIP «пошкодженим». Але це не заважає спеціально написаному завантажувачу отримати payload. (‘Zombie ZIP’ slips malware past 98% of antivirus engines | news | SC Media)
👨💻 Автор дослідження — Chris Aziz із Bombadil Systems. Він опублікував proof-of-concept код, який демонструє створення таких архівів:
Zombie ZIP PoC (loader_poc.py)
⚠️ Чому це небезпечно?
Проблема не лише у ZIP-файлах. Багато антивірусів, поштових шлюзів та sandbox-систем покладаються на «швидкий аналіз» архівів без повної перевірки структури. Це відкриває можливість:
• доставляти malware через email-вкладення;
• обходити корпоративні системи фільтрації;
• приховувати payload від автоматичного аналізу;
• використовувати ZIP як контейнер для подальшого stage-loader зараження. (Zombie ZIP method can fool antivirus during the first scan - Security Boulevard)
📊 Найгірше — рівень виявлення.
За результатами тестів Chris Aziz:
• лише 1 із 51 антивірусів на VirusTotal виявив загрозу;
• інші пропустили архів як «безпечний»;
• окремі джерела повідомляють про 60 із 63 AV-движків, що не змогли детектувати атаку (~95%). (‘Zombie ZIP’ slips malware past 98% of antivirus engines | news | SC Media)
Фактично це означає, що багато сучасних систем захисту все ще довіряють метаданим архіву більше, ніж його реальному вмісту — проблема, відома ще з 2004 року. (CVE-2004-0935 Security Vulnerability & Exploit Details)
🛡 Висновок:
Антивірус — це лише один із рівнів захисту. Якщо користувач запускає невідомі loader’и, «patcher.exe», «viewer.exe» або інші допоміжні файли з архіву — жоден ZIP-фільтр не врятує.
А «пошкоджений архів», який «чомусь не відкривається», може бути не помилкою, а частиною атаки.
SC Media
‘Zombie ZIP’ slips malware past 98% of antivirus engines
A simple exploit causes AVs to treat compressed data as uncompressed bytes.
👍1🔥1
🐙 Megalodon: нова масштабна атака на GitHub скомпрометувала понад 5 500 репозиторіїв за кілька годин
Дослідники з SafeDep виявили одну з найбільших supply chain-атак проти екосистеми GitHub за останній час.
Кампанію назвали Megalodon — через її масштаб та агресивність. За менш ніж 6 годин зловмисники змогли внести шкідливі зміни у понад 5 500 репозиторіїв.
Як працювала атака
Атакувальники використовували фейкові акаунти та маскувалися під автоматизованих CI/CD-ботів із назвами на кшталт:
- build-bot
- auto-ci
-pipeline-bot
- ci-bot
Коміти виглядали як звичайні технічні оновлення для GitHub Actions або CI/CD workflows, тому багато розробників не помічали загрози під час рев’ю коду.
Основна ціль — не сам код застосунку, а інфраструктура збірки та деплою.
Після прийняття шкідливого коміту GitHub Actions автоматично запускав payload, який починав збирати:
- AWS/GCP/Azure ключі
- SSH-ключі
- .env файли
- Docker та Kubernetes конфіги
- Vault/Terraform credentials
- GitHub tokens
- OIDC credentials
- API-ключі та database connection strings
Усе це передавалося на сервер зловмисників.
Чому це особливо небезпечно
CI/CD системи часто мають доступ до production-інфраструктури, контейнерів, хмарних сервісів та систем автоматичного деплою.
Тобто компрометація pipeline — це не просто “шкідливий скрипт у репозиторії”, а потенційний доступ до:
серверів,
Kubernetes-кластерів,
хмарної інфраструктури,
npm/pypi publish tokens,
production secrets.
Фактично Megalodon показує нову тенденцію:
🔻 атакують уже не лише залежності чи пакети,
🔻 атакують сам процес створення програмного забезпечення.
Є й інша проблема
Відомо, що частина заражених репозиторіїв встигла опублікувати скомпрометовані npm-пакети.
Одним із прикладів став проєкт Tiledesk, де заражені версії були опубліковані самими розробниками — вони просто не помітили бекдор у CI/CD workflow.
Що варто зробити розробникам вже зараз
▪️ Перевірити GitHub Actions workflows на підозрілі зміни
▪️ Переглянути коміти від “ботів” за останні дні
▪️ Ротувати всі CI/CD secrets та cloud credentials
▪️ Мінімізувати права GitHub tokens
▪️ Заборонити автоматичний запуск workflow із неперевірених pull request
▪️ Увімкнути branch protection та mandatory reviews для workflow-файлів
▪️ Ставитися до CI/CD як до критичної production-інфраструктури
Megalodon — це ще одне нагадування, що сьогодні атака на розробника може бути ефективнішою за атаку на датацентр.
Дослідники з SafeDep виявили одну з найбільших supply chain-атак проти екосистеми GitHub за останній час.
Кампанію назвали Megalodon — через її масштаб та агресивність. За менш ніж 6 годин зловмисники змогли внести шкідливі зміни у понад 5 500 репозиторіїв.
Як працювала атака
Атакувальники використовували фейкові акаунти та маскувалися під автоматизованих CI/CD-ботів із назвами на кшталт:
- build-bot
- auto-ci
-pipeline-bot
- ci-bot
Коміти виглядали як звичайні технічні оновлення для GitHub Actions або CI/CD workflows, тому багато розробників не помічали загрози під час рев’ю коду.
Основна ціль — не сам код застосунку, а інфраструктура збірки та деплою.
Після прийняття шкідливого коміту GitHub Actions автоматично запускав payload, який починав збирати:
- AWS/GCP/Azure ключі
- SSH-ключі
- .env файли
- Docker та Kubernetes конфіги
- Vault/Terraform credentials
- GitHub tokens
- OIDC credentials
- API-ключі та database connection strings
Усе це передавалося на сервер зловмисників.
Чому це особливо небезпечно
CI/CD системи часто мають доступ до production-інфраструктури, контейнерів, хмарних сервісів та систем автоматичного деплою.
Тобто компрометація pipeline — це не просто “шкідливий скрипт у репозиторії”, а потенційний доступ до:
серверів,
Kubernetes-кластерів,
хмарної інфраструктури,
npm/pypi publish tokens,
production secrets.
Фактично Megalodon показує нову тенденцію:
🔻 атакують уже не лише залежності чи пакети,
🔻 атакують сам процес створення програмного забезпечення.
Є й інша проблема
Відомо, що частина заражених репозиторіїв встигла опублікувати скомпрометовані npm-пакети.
Одним із прикладів став проєкт Tiledesk, де заражені версії були опубліковані самими розробниками — вони просто не помітили бекдор у CI/CD workflow.
Що варто зробити розробникам вже зараз
▪️ Перевірити GitHub Actions workflows на підозрілі зміни
▪️ Переглянути коміти від “ботів” за останні дні
▪️ Ротувати всі CI/CD secrets та cloud credentials
▪️ Мінімізувати права GitHub tokens
▪️ Заборонити автоматичний запуск workflow із неперевірених pull request
▪️ Увімкнути branch protection та mandatory reviews для workflow-файлів
▪️ Ставитися до CI/CD як до критичної production-інфраструктури
Megalodon — це ще одне нагадування, що сьогодні атака на розробника може бути ефективнішою за атаку на датацентр.
👍1🔥1
📌 Kali365 — PhaaS-платформа, на яку попереджає ФБР (IC3 PSA 2026-05-21)
ФБР через IC3 офіційно попередило про нову phishing-as-a-service (PhaaS) платформу під назвою Kali365, яка активно розповсюджується через Telegram і використовується для атак на Microsoft 365 середовища.
На відміну від класичного фішингу, ця платформа працює не через крадіжку паролів, а через викрадення OAuth-токенів доступу, що дозволяє обходити MFA.
⚙️ Як працює Kali365
За описом IC3, атака базується на OAuth device code flow abuse:
- жертва отримує фішинговий лист (часто під виглядом DocuSign, SharePoint, Adobe тощо);
- її просять ввести код на легітимній сторінці Microsoft;
- користувач проходить справжню MFA-аутентифікацію;
- після цього атакуючі отримують access + refresh tokens.
👉 результат: доступ до Microsoft 365 без пароля і без повторної MFA
🎯 Чому це небезпечно
ФБР підкреслює ключову проблему:
- MFA не блокує атаку;
- користувач авторизується на реальному Microsoft сайті;
- компрометується не пароль, а сесія (token theft).
Це означає:
- доступ до Outlook;
- доступ до Teams;
- доступ до OneDrive;
- без повторного логіну.
🧠 Чим Kali365 відрізняється від “звичайного фішингу”
Це не “класичний фейковий логін-екран”.
Kali365:
- використовує легітимний Microsoft flow;
- не краде пароль напряму;
- краде сесію після успішної MFA.
🧩 Чому це важливо для кібербезпеки
ФБР фактично фіксує зсув:
атаки більше не ламають MFA — вони обходять його через токени.
І це ключова тенденція 2025–2026 років:
- device code phishing;
- OAuth consent abuse;
- session hijacking.
⚠️ Висновок
Kali365 — це приклад того, як кіберзлочинність перейшла в модель SaaS:
- продається як сервіс (PhaaS);
- розповсюджується через Telegram;
- знижує поріг входу для атак;
- атакує не пароль, а сесію.
ФБР через IC3 офіційно попередило про нову phishing-as-a-service (PhaaS) платформу під назвою Kali365, яка активно розповсюджується через Telegram і використовується для атак на Microsoft 365 середовища.
На відміну від класичного фішингу, ця платформа працює не через крадіжку паролів, а через викрадення OAuth-токенів доступу, що дозволяє обходити MFA.
⚙️ Як працює Kali365
За описом IC3, атака базується на OAuth device code flow abuse:
- жертва отримує фішинговий лист (часто під виглядом DocuSign, SharePoint, Adobe тощо);
- її просять ввести код на легітимній сторінці Microsoft;
- користувач проходить справжню MFA-аутентифікацію;
- після цього атакуючі отримують access + refresh tokens.
👉 результат: доступ до Microsoft 365 без пароля і без повторної MFA
🎯 Чому це небезпечно
ФБР підкреслює ключову проблему:
- MFA не блокує атаку;
- користувач авторизується на реальному Microsoft сайті;
- компрометується не пароль, а сесія (token theft).
Це означає:
- доступ до Outlook;
- доступ до Teams;
- доступ до OneDrive;
- без повторного логіну.
🧠 Чим Kali365 відрізняється від “звичайного фішингу”
Це не “класичний фейковий логін-екран”.
Kali365:
- використовує легітимний Microsoft flow;
- не краде пароль напряму;
- краде сесію після успішної MFA.
🧩 Чому це важливо для кібербезпеки
ФБР фактично фіксує зсув:
атаки більше не ламають MFA — вони обходять його через токени.
І це ключова тенденція 2025–2026 років:
- device code phishing;
- OAuth consent abuse;
- session hijacking.
⚠️ Висновок
Kali365 — це приклад того, як кіберзлочинність перейшла в модель SaaS:
- продається як сервіс (PhaaS);
- розповсюджується через Telegram;
- знижує поріг входу для атак;
- атакує не пароль, а сесію.
👍1🔥1
🔐 Microsoft змінює ключі Secure Boot: що це означає для Windows і Linux у 2026 році
У червні 2026 року Microsoft почне завершення життєвого циклу старих сертифікатів Secure Boot, які використовувались у Windows-пристроях ще з 2011 року. Компанія вже розгортає нові ключі «Windows UEFI CA 2023», а системи без оновлення поступово втратять частину захисту. (Secure Boot playbook for certificates expiring in 2026)
📌 Що таке Secure Boot?
Secure Boot — це механізм UEFI, який перевіряє цифрові підписи завантажувача ОС, драйверів та EFI-компонентів ще до запуску Windows. Його головне завдання — не допустити запуску rootkit та bootkit-шкідників, які заражають систему до старту ОС. (June 2026: Secure Boot Certificates are expiring - Help is on ...)
Система працює на основі набору сертифікатів і ключів довіри, записаних у firmware материнської плати.
📌 Чому Microsoft змінює ключі?
Поточні сертифікати «Microsoft KEK CA 2011» та «Microsoft UEFI CA 2011» були випущені ще 15 років тому й починають втрачати чинність у червні 2026 року. (Windows Secure Boot certificate expiration and CA updates)
Microsoft замінює їх на нові:
• Microsoft KEK CA 2023
• Windows UEFI CA 2023
• Microsoft Option ROM CA 2023 (June 2026: Secure Boot Certificates are expiring - Help is on ...)
Фактично — це «перевипуск кореня довіри» для всього процесу завантаження Windows.
📌 Що буде, якщо нічого не робити?
Комп’ютер не перетвориться на «цеглу» й Windows, швидше за все, продовжить запускатися. Але є нюанс:
⚠️ система перестане отримувати оновлення Secure Boot та bootloader;
⚠️ нові записи DBX (чорний список скомпрометованих завантажувачів) більше не надходитимуть;
⚠️ пристрій стане вразливішим до bootkit/rootkit-атак;
⚠️ майбутні версії Windows можуть відмовитись встановлюватися на системи без нових ключів. (Millions of PCs may lose protection: Microsoft sets critical update deadline)
📌 Чи торкнеться це Linux?
Так — і це вже викликало занепокоєння у Linux-спільноті. Багато дистрибутивів використовують Microsoft UEFI CA для роботи Secure Boot. Якщо firmware або shim/GRUB не підтримують нові сертифікати, деякі системи можуть перестати нормально завантажуватись із увімкненим Secure Boot. (UEFI)
Особливо це стосується:
• старих ноутбуків;
• систем із кастомними Secure Boot ключами;
• dual-boot Windows/Linux;
• застарілих UEFI firmware без оновлень від виробника. (June 2026: Secure Boot Certificates are expiring - Help is on ...)
📌 Як Microsoft розгортає оновлення?
Оновлення ключів вже поширюються через Windows Update. Частині пристроїв також знадобиться оновлення BIOS/UEFI від виробника. (Secure Boot playbook for certificates expiring in 2026)
У Windows 11 можна перевірити статус Secure Boot у:
Windows Security → Device Security → Secure Boot. (Millions of PCs may lose protection: Microsoft sets critical update deadline)
📌 Чому це важливо?
Secure Boot — один із фундаментальних механізмів сучасної безпеки ПК. Саме він блокує запуск модифікованих bootloader, UEFI malware та низькорівневих rootkit ще до старту ОС. Після появи UEFI-bootkit BlackLotus індустрія почала активніше оновлювати цей механізм захисту. (UEFI)
Але одночасно це ще раз демонструє, наскільки сучасні ПК залежать від централізованої інфраструктури довіри Microsoft навіть у процесі завантаження альтернативних ОС.
У червні 2026 року Microsoft почне завершення життєвого циклу старих сертифікатів Secure Boot, які використовувались у Windows-пристроях ще з 2011 року. Компанія вже розгортає нові ключі «Windows UEFI CA 2023», а системи без оновлення поступово втратять частину захисту. (Secure Boot playbook for certificates expiring in 2026)
📌 Що таке Secure Boot?
Secure Boot — це механізм UEFI, який перевіряє цифрові підписи завантажувача ОС, драйверів та EFI-компонентів ще до запуску Windows. Його головне завдання — не допустити запуску rootkit та bootkit-шкідників, які заражають систему до старту ОС. (June 2026: Secure Boot Certificates are expiring - Help is on ...)
Система працює на основі набору сертифікатів і ключів довіри, записаних у firmware материнської плати.
📌 Чому Microsoft змінює ключі?
Поточні сертифікати «Microsoft KEK CA 2011» та «Microsoft UEFI CA 2011» були випущені ще 15 років тому й починають втрачати чинність у червні 2026 року. (Windows Secure Boot certificate expiration and CA updates)
Microsoft замінює їх на нові:
• Microsoft KEK CA 2023
• Windows UEFI CA 2023
• Microsoft Option ROM CA 2023 (June 2026: Secure Boot Certificates are expiring - Help is on ...)
Фактично — це «перевипуск кореня довіри» для всього процесу завантаження Windows.
📌 Що буде, якщо нічого не робити?
Комп’ютер не перетвориться на «цеглу» й Windows, швидше за все, продовжить запускатися. Але є нюанс:
⚠️ система перестане отримувати оновлення Secure Boot та bootloader;
⚠️ нові записи DBX (чорний список скомпрометованих завантажувачів) більше не надходитимуть;
⚠️ пристрій стане вразливішим до bootkit/rootkit-атак;
⚠️ майбутні версії Windows можуть відмовитись встановлюватися на системи без нових ключів. (Millions of PCs may lose protection: Microsoft sets critical update deadline)
📌 Чи торкнеться це Linux?
Так — і це вже викликало занепокоєння у Linux-спільноті. Багато дистрибутивів використовують Microsoft UEFI CA для роботи Secure Boot. Якщо firmware або shim/GRUB не підтримують нові сертифікати, деякі системи можуть перестати нормально завантажуватись із увімкненим Secure Boot. (UEFI)
Особливо це стосується:
• старих ноутбуків;
• систем із кастомними Secure Boot ключами;
• dual-boot Windows/Linux;
• застарілих UEFI firmware без оновлень від виробника. (June 2026: Secure Boot Certificates are expiring - Help is on ...)
📌 Як Microsoft розгортає оновлення?
Оновлення ключів вже поширюються через Windows Update. Частині пристроїв також знадобиться оновлення BIOS/UEFI від виробника. (Secure Boot playbook for certificates expiring in 2026)
У Windows 11 можна перевірити статус Secure Boot у:
Windows Security → Device Security → Secure Boot. (Millions of PCs may lose protection: Microsoft sets critical update deadline)
📌 Чому це важливо?
Secure Boot — один із фундаментальних механізмів сучасної безпеки ПК. Саме він блокує запуск модифікованих bootloader, UEFI malware та низькорівневих rootkit ще до старту ОС. Після появи UEFI-bootkit BlackLotus індустрія почала активніше оновлювати цей механізм захисту. (UEFI)
Але одночасно це ще раз демонструє, наскільки сучасні ПК залежать від централізованої інфраструктури довіри Microsoft навіть у процесі завантаження альтернативних ОС.
TECHCOMMUNITY.MICROSOFT.COM
Secure Boot playbook for certificates expiring in 2026
Explore tools and step-by-step guidance to help you proactively update your Secure Boot certificates.
👍2❤1
🇪🇺 ЄС посилює контроль над Big Tech: наступна ціль — хмари та ШІ
European Union планує розширити дію свого ключового антимонопольного інструменту — Digital Markets Act (DMA) — на хмарні сервіси та системи штучного інтелекту.
📌 Що відбувається:
— DMA вже обмежує вплив технологічних гігантів (Google, Amazon, Apple, Microsoft та ін.)
— Тепер регулятори хочуть перевірити, чи повинні хмарні провайдери та AI-сервіси отримати статус «gatekeeper»
— Основна мета — зробити ринки більш конкурентними та відкритими для інших гравців
— Йдеться також про кращу сумісність (interoperability) і переносимість даних
📌 Чому це важливо:
Хмарні сервіси та ШІ стали новим «полем битви» Big Tech. Контроль над ними означає контроль над інфраструктурою майбутнього — від бізнесу до державних сервісів.
📌 Реакція:
— Частина компаній (зокрема Apple) вже заявляє про ризики для безпеки та інновацій
— Європейські споживчі організації навпаки закликають до ще жорсткішого контролю
📊 Контекст:
DMA діє з 2023 року і вже змушує великі компанії змінювати поведінку — наприклад, відкривати свої екосистеми для конкурентів (https://www.reuters.com/legal/litigation/eu-rules-reining-big-tech-will-now-target-cloud-services-ai-regulators-say-2026-04-28/)
⚠️ Висновки та наслідки:
1. Більше регуляції = менше монополії
Ринок хмар і ШІ стане більш відкритим для менших гравців.
2. Зростання витрат для Big Tech
Компанії будуть змушені змінювати архітектуру сервісів і відкривати API.
3. Повільніша інновація (ймовірно)
Жорстке регулювання може гальмувати розвиток нових продуктів — особливо в AI.
4. Посилення «цифрового суверенітету» ЄС
Європа продовжує курс на зменшення залежності від американських технологій.
5. Глобальний ефект
Як і GDPR, ці правила можуть стати стандартом де-факто у світі.
💬 Фактично ЄС намагається зробити те, що інші лише обговорюють: поставити під контроль не лише Big Tech, а й інфраструктуру майбутнього — хмару та штучний інтелект.
European Union планує розширити дію свого ключового антимонопольного інструменту — Digital Markets Act (DMA) — на хмарні сервіси та системи штучного інтелекту.
📌 Що відбувається:
— DMA вже обмежує вплив технологічних гігантів (Google, Amazon, Apple, Microsoft та ін.)
— Тепер регулятори хочуть перевірити, чи повинні хмарні провайдери та AI-сервіси отримати статус «gatekeeper»
— Основна мета — зробити ринки більш конкурентними та відкритими для інших гравців
— Йдеться також про кращу сумісність (interoperability) і переносимість даних
📌 Чому це важливо:
Хмарні сервіси та ШІ стали новим «полем битви» Big Tech. Контроль над ними означає контроль над інфраструктурою майбутнього — від бізнесу до державних сервісів.
📌 Реакція:
— Частина компаній (зокрема Apple) вже заявляє про ризики для безпеки та інновацій
— Європейські споживчі організації навпаки закликають до ще жорсткішого контролю
📊 Контекст:
DMA діє з 2023 року і вже змушує великі компанії змінювати поведінку — наприклад, відкривати свої екосистеми для конкурентів (https://www.reuters.com/legal/litigation/eu-rules-reining-big-tech-will-now-target-cloud-services-ai-regulators-say-2026-04-28/)
⚠️ Висновки та наслідки:
1. Більше регуляції = менше монополії
Ринок хмар і ШІ стане більш відкритим для менших гравців.
2. Зростання витрат для Big Tech
Компанії будуть змушені змінювати архітектуру сервісів і відкривати API.
3. Повільніша інновація (ймовірно)
Жорстке регулювання може гальмувати розвиток нових продуктів — особливо в AI.
4. Посилення «цифрового суверенітету» ЄС
Європа продовжує курс на зменшення залежності від американських технологій.
5. Глобальний ефект
Як і GDPR, ці правила можуть стати стандартом де-факто у світі.
💬 Фактично ЄС намагається зробити те, що інші лише обговорюють: поставити під контроль не лише Big Tech, а й інфраструктуру майбутнього — хмару та штучний інтелект.
👍2😐1
Небезпечні «апаратні криптогаманці» з маркетплейсів: як користувачам крадуть криптовалюту
На китайських торгових майданчиках дедалі частіше з’являються підроблені апаратні криптогаманці, які зовні майже не відрізняються від оригінальних пристроїв відомих брендів. Проблема в тому, що частина таких пристроїв уже на заводі модифікована для викрадення seed-фраз, PIN-кодів або приватних ключів.
Зловмисники використовують кілька схем:
- прошивка зі шкідливим кодом;
- попередньо згенерована seed-фраза в коробці;
- підроблені мобільні застосунки;
- модифіковані USB-контролери;
- фальшиві QR-коди для «активації» гаманця;
- пристрої-клони, що імітують популярні бренди.
Особливо небезпечна ситуація виникає тоді, коли користувач купує гаманець «зі знижкою», «без коробки» або «новий, але відкритий». У таких випадках ризик компрометації значно вищий.
Як працює схема викрадення
Найпоширеніший сценарій виглядає так:
1. Користувач купує гаманець на сторонньому маркетплейсі.
2. У коробці вже лежить «готова seed-фраза».
3. Людині пропонують просто відновити гаманець замість створення нового.
4. Після поповнення рахунку зловмисник, який знає seed-фразу, отримує повний доступ до активів і виводить кошти.
Інший варіант — шкідлива прошивка, яка непомітно передає приватні дані через комп’ютер або мобільний застосунок.
Як зменшити ризики
Купуйте лише у виробника або офіційних партнерів
Найкращий варіант — замовлення через офіційний сайт виробника або перевірених реселерів.
Популярні виробники:
- Ledger
- Trezor
- SafePal
- Keystone
Ніколи не використовуйте seed-фразу з коробки
Апаратний гаманець має генерувати seed-фразу лише під час першого запуску. Якщо фраза вже надрукована на картці — це критичний сигнал небезпеки.
Перевіряйте цілісність упаковки
Звертайте увагу на:
- пломби;
- захисні наклейки;
- ознаки повторного відкриття;
-невідповідність серійних номерів.
Оновлюйте прошивку тільки з офіційних джерел
Не встановлюйте ПЗ із Telegram-каналів, форумів або «дзеркал». Завантажуйте застосунки лише з офіційних сайтів виробника.
Генеруйте новий гаманець самостійно
Після купівлі:
- скиньте пристрій до заводських налаштувань;
- створіть нову seed-фразу;
- переконайтеся, що вона генерується локально на самому пристрої.
Не фотографуйте seed-фразу
Не зберігайте її:
- у галереї смартфона;
- у хмарних сервісах;
- у нотатках;
- у месенджерах.
Краще використовувати паперовий запис або металеві пластини для резервного збереження.
Використовуйте «passphrase»
Багато сучасних гаманців підтримують додаткову секретну фразу поверх seed. Це створює ще один рівень захисту навіть у разі витоку основної seed-фрази.
Остерігайтеся «занадто вигідних» пропозицій
Якщо пристрій коштує вдвічі дешевше за ринкову ціну — це привід насторожитися. Для апаратних криптогаманців наднизька ціна часто означає підробку або модифікований пристрій.
Висновок
Апаратний гаманець сам по собі не гарантує безпеку. Якщо пристрій скомпрометований ще до покупки, користувач фактично добровільно передає свої ключі зловмисникам.
У світі криптовалют головне правило залишається незмінним:
“Not your keys — not your coins.”
Тому безпечніше витратити трохи більше часу й коштів на перевірений пристрій, ніж втратити всі активи через одну «вигідну» покупку.
На китайських торгових майданчиках дедалі частіше з’являються підроблені апаратні криптогаманці, які зовні майже не відрізняються від оригінальних пристроїв відомих брендів. Проблема в тому, що частина таких пристроїв уже на заводі модифікована для викрадення seed-фраз, PIN-кодів або приватних ключів.
Зловмисники використовують кілька схем:
- прошивка зі шкідливим кодом;
- попередньо згенерована seed-фраза в коробці;
- підроблені мобільні застосунки;
- модифіковані USB-контролери;
- фальшиві QR-коди для «активації» гаманця;
- пристрої-клони, що імітують популярні бренди.
Особливо небезпечна ситуація виникає тоді, коли користувач купує гаманець «зі знижкою», «без коробки» або «новий, але відкритий». У таких випадках ризик компрометації значно вищий.
Як працює схема викрадення
Найпоширеніший сценарій виглядає так:
1. Користувач купує гаманець на сторонньому маркетплейсі.
2. У коробці вже лежить «готова seed-фраза».
3. Людині пропонують просто відновити гаманець замість створення нового.
4. Після поповнення рахунку зловмисник, який знає seed-фразу, отримує повний доступ до активів і виводить кошти.
Інший варіант — шкідлива прошивка, яка непомітно передає приватні дані через комп’ютер або мобільний застосунок.
Як зменшити ризики
Купуйте лише у виробника або офіційних партнерів
Найкращий варіант — замовлення через офіційний сайт виробника або перевірених реселерів.
Популярні виробники:
- Ledger
- Trezor
- SafePal
- Keystone
Ніколи не використовуйте seed-фразу з коробки
Апаратний гаманець має генерувати seed-фразу лише під час першого запуску. Якщо фраза вже надрукована на картці — це критичний сигнал небезпеки.
Перевіряйте цілісність упаковки
Звертайте увагу на:
- пломби;
- захисні наклейки;
- ознаки повторного відкриття;
-невідповідність серійних номерів.
Оновлюйте прошивку тільки з офіційних джерел
Не встановлюйте ПЗ із Telegram-каналів, форумів або «дзеркал». Завантажуйте застосунки лише з офіційних сайтів виробника.
Генеруйте новий гаманець самостійно
Після купівлі:
- скиньте пристрій до заводських налаштувань;
- створіть нову seed-фразу;
- переконайтеся, що вона генерується локально на самому пристрої.
Не фотографуйте seed-фразу
Не зберігайте її:
- у галереї смартфона;
- у хмарних сервісах;
- у нотатках;
- у месенджерах.
Краще використовувати паперовий запис або металеві пластини для резервного збереження.
Використовуйте «passphrase»
Багато сучасних гаманців підтримують додаткову секретну фразу поверх seed. Це створює ще один рівень захисту навіть у разі витоку основної seed-фрази.
Остерігайтеся «занадто вигідних» пропозицій
Якщо пристрій коштує вдвічі дешевше за ринкову ціну — це привід насторожитися. Для апаратних криптогаманців наднизька ціна часто означає підробку або модифікований пристрій.
Висновок
Апаратний гаманець сам по собі не гарантує безпеку. Якщо пристрій скомпрометований ще до покупки, користувач фактично добровільно передає свої ключі зловмисникам.
У світі криптовалют головне правило залишається незмінним:
“Not your keys — not your coins.”
Тому безпечніше витратити трохи більше часу й коштів на перевірений пристрій, ніж втратити всі активи через одну «вигідну» покупку.
👍1🔥1
🔍 Користувачі втомилися від ШІ у пошуку Google — і масово переходять на DuckDuckGo
Після презентації нових AI-функцій на Google I/O 2026 встановлення браузера та пошуковика DuckDuckGo у США зросли приблизно на 30%. На iOS стрибок подекуди сягав майже 70%.
Причина — невдоволення тим, що Google дедалі агресивніше вбудовує ШІ у пошук: AI-відповіді, «розумні» підказки, агентні функції та автоматично згенеровані резюме тепер стають частиною звичайного пошуку без можливості повністю відмовитися від них.
Генеральний директор DuckDuckGo Ґабріель Вайнберґ заявив, що люди просто хочуть вибору, а Google фактично «нав’язує» AI-пошук користувачам.
На цьому фоні різко зріс інтерес до:
• DuckDuckGo;
• AI-free режиму noai.duckduckgo.com;
• приватних та мінімалістичних пошукових систем без ШІ-вставок.
Іронічно, але ще кілька років тому Google висміював «сині посилання» як застарілий формат пошуку. Тепер частина користувачів, схоже, хоче повернення саме до них.
Схоже, у 2026 році боротьба точиться вже не лише за якість пошуку чи приватність — а й за право користувача самостійно вирішувати, чи потрібен йому ШІ взагалі.
Після презентації нових AI-функцій на Google I/O 2026 встановлення браузера та пошуковика DuckDuckGo у США зросли приблизно на 30%. На iOS стрибок подекуди сягав майже 70%.
Причина — невдоволення тим, що Google дедалі агресивніше вбудовує ШІ у пошук: AI-відповіді, «розумні» підказки, агентні функції та автоматично згенеровані резюме тепер стають частиною звичайного пошуку без можливості повністю відмовитися від них.
Генеральний директор DuckDuckGo Ґабріель Вайнберґ заявив, що люди просто хочуть вибору, а Google фактично «нав’язує» AI-пошук користувачам.
На цьому фоні різко зріс інтерес до:
• DuckDuckGo;
• AI-free режиму noai.duckduckgo.com;
• приватних та мінімалістичних пошукових систем без ШІ-вставок.
Іронічно, але ще кілька років тому Google висміював «сині посилання» як застарілий формат пошуку. Тепер частина користувачів, схоже, хоче повернення саме до них.
Схоже, у 2026 році боротьба точиться вже не лише за якість пошуку чи приватність — а й за право користувача самостійно вирішувати, чи потрібен йому ШІ взагалі.
👍2
Поки більшість AI-індустрії будує дедалі складніші прошарки абстракцій навколо Python, у SpaceX, схоже, вирішили піти у протилежний бік.
Elon Musk заявив, що компанія майже завершила розробку V1.0 власного стеку навчання ШІ, написаного мовою C та орієнтованого на роботу «максимально близько до bare metal». Система створюється для кластера приблизно з 220 000 GPU NVIDIA GB300, з'єднаних мережею 800G.
За словами Маска, новий підхід може забезпечити кратний приріст швидкодії порівняно з сучасними AI-фреймворками на кшталт JAX. Причина проста: менше абстракцій — менше накладних витрат.
Сьогодні індустрія ШІ значною мірою тримається на Python — мові, яка чудово підходить для швидкої розробки, експериментів та величезної екосистеми бібліотек. Але більшість «магії» під капотом усе одно працює через низькорівневі компоненти на C/C++, CUDA або Rust.
Проблема в тому, що кожен додатковий шар абстракції має ціну:
— втрата продуктивності;
— вищі затримки;
— більше споживання енергії;
— складність оптимізації;
— величезні апаратні витрати для компенсації програмної неефективності.
І поки для звичайних задач це майже непомітно, на масштабах датацентрів із сотнями тисяч GPU навіть 5–10% втрат перетворюються на колосальні суми.
Фактично SpaceX робить ставку на стару інженерну ідею:
Це особливо цікаво на фоні сучасної культури розробки, де:
— фреймворки нашаровуються на фреймворки;
— залежності тягнуть сотні мегабайт;
— прості задачі вимагають десятків бібліотек;
— продуктивність часто приноситься у жертву «зручності процесу».
Поки що незалежних тестів або технічних деталей немає, тому до заяв про «10× швидше» варто ставитися обережно. Але сам факт такого руху показовий.
Можливо, ми спостерігаємо початок нового циклу в індустрії:
повернення від культу процесу, абстракцій та нескінченних прошарків — до інженерної культури, де ефективність, контроль над системою та розуміння того, як усе працює під капотом, знову стають конкурентною перевагою.
Elon Musk заявив, що компанія майже завершила розробку V1.0 власного стеку навчання ШІ, написаного мовою C та орієнтованого на роботу «максимально близько до bare metal». Система створюється для кластера приблизно з 220 000 GPU NVIDIA GB300, з'єднаних мережею 800G.
За словами Маска, новий підхід може забезпечити кратний приріст швидкодії порівняно з сучасними AI-фреймворками на кшталт JAX. Причина проста: менше абстракцій — менше накладних витрат.
Сьогодні індустрія ШІ значною мірою тримається на Python — мові, яка чудово підходить для швидкої розробки, експериментів та величезної екосистеми бібліотек. Але більшість «магії» під капотом усе одно працює через низькорівневі компоненти на C/C++, CUDA або Rust.
Проблема в тому, що кожен додатковий шар абстракції має ціну:
— втрата продуктивності;
— вищі затримки;
— більше споживання енергії;
— складність оптимізації;
— величезні апаратні витрати для компенсації програмної неефективності.
І поки для звичайних задач це майже непомітно, на масштабах датацентрів із сотнями тисяч GPU навіть 5–10% втрат перетворюються на колосальні суми.
Фактично SpaceX робить ставку на стару інженерну ідею:
не «залити проблему залізом», а максимально ефективно використовувати наявне.
Це особливо цікаво на фоні сучасної культури розробки, де:
— фреймворки нашаровуються на фреймворки;
— залежності тягнуть сотні мегабайт;
— прості задачі вимагають десятків бібліотек;
— продуктивність часто приноситься у жертву «зручності процесу».
Поки що незалежних тестів або технічних деталей немає, тому до заяв про «10× швидше» варто ставитися обережно. Але сам факт такого руху показовий.
Можливо, ми спостерігаємо початок нового циклу в індустрії:
повернення від культу процесу, абстракцій та нескінченних прошарків — до інженерної культури, де ефективність, контроль над системою та розуміння того, як усе працює під капотом, знову стають конкурентною перевагою.
Gagadget
SpaceX built an AI training system in C — and claims it's 10x faster than Google's JAX
Musk's team has nearly finished a bare-metal AI training stack mapped to 220,000 Nvidia GB300 ...
❤3
🇨🇦 У Канаді просувають законопроєкти, які можуть серйозно вдарити по цифровій приватності
У Канаді розгорівся конфлікт навколо нових законопроєктів Bill C-8 та Bill C-22, які розширюють повноваження держави у сфері кібербезпеки та доступу до цифрових даних.
🔹 Bill C-8 офіційно подається як закон для захисту критичної інфраструктури — телекомунікацій, банків, енергетики та транспорту. Але критики попереджають, що документ дає уряду дуже широкі повноваження щодо контролю телеком-мереж та обміну даними.
🔹 Значно більше суперечок викликав Bill C-22 (“Lawful Access Act”). На думку правозахисників та IT-компаній, він може створити механізми для:
• доступу держави до зашифрованих даних;
• прихованих вимог до сервісів впроваджувати засоби стеження;
• зберігання метаданих користувачів;
• потенційного послаблення end-to-end шифрування.
Проти законопроєкту вже виступили:
• Apple
• Google
• Signal
• ExpressVPN
• Windscribe
Деякі сервіси вже заявили, що можуть піти з канадського ринку, якщо закон ухвалять у нинішньому вигляді.
Представники Apple та Google попереджають: навіть якщо у тексті прямо не написано “зламати шифрування”, механізми закону можуть змусити компанії створювати бекдори або приховані інструменти доступу для спецслужб.
Ситуація нагадує дискусії навколо подібних законів у Великій Британії та Австралії, де влада також намагається отримати доступ до зашифрованих комунікацій під приводом боротьби зі злочинністю та кіберзагрозами.
Фактично, Канада зараз опинилася у центрі глобального конфлікту між приватністю користувачів та бажанням держав отримати більше інструментів цифрового контролю.
У Канаді розгорівся конфлікт навколо нових законопроєктів Bill C-8 та Bill C-22, які розширюють повноваження держави у сфері кібербезпеки та доступу до цифрових даних.
🔹 Bill C-8 офіційно подається як закон для захисту критичної інфраструктури — телекомунікацій, банків, енергетики та транспорту. Але критики попереджають, що документ дає уряду дуже широкі повноваження щодо контролю телеком-мереж та обміну даними.
🔹 Значно більше суперечок викликав Bill C-22 (“Lawful Access Act”). На думку правозахисників та IT-компаній, він може створити механізми для:
• доступу держави до зашифрованих даних;
• прихованих вимог до сервісів впроваджувати засоби стеження;
• зберігання метаданих користувачів;
• потенційного послаблення end-to-end шифрування.
Проти законопроєкту вже виступили:
• Apple
• Signal
• ExpressVPN
• Windscribe
Деякі сервіси вже заявили, що можуть піти з канадського ринку, якщо закон ухвалять у нинішньому вигляді.
Представники Apple та Google попереджають: навіть якщо у тексті прямо не написано “зламати шифрування”, механізми закону можуть змусити компанії створювати бекдори або приховані інструменти доступу для спецслужб.
Ситуація нагадує дискусії навколо подібних законів у Великій Британії та Австралії, де влада також намагається отримати доступ до зашифрованих комунікацій під приводом боротьби зі злочинністю та кіберзагрозами.
Фактично, Канада зараз опинилася у центрі глобального конфлікту між приватністю користувачів та бажанням держав отримати більше інструментів цифрового контролю.
Fasken
Bill C‑22: The Lawful Access Act Reintroduces Lawful Access in Parliament After the Government of Canada’s Abortive Attempt to…
Take two: The Government of Canada introduces Bill C-22, the Lawful Access Act, after facing criticism of its first attempt to enact a lawful access regime
🤬1😐1
⚠️ Новий тип браузерного шпигунства: дослідники навчилися визначати, які сайти та програми відкриті у користувача, аналізуючи активність SSD-диска через звичайний браузерний API.
Метод отримав назву FROST (Fingerprinting Remotely using OPFS-based SSD Timing). Його описали дослідники з Технічного університету Граца (Австрія). Атака не потребує дозволів, встановлення ПЗ чи взаємодії з боку жертви — достатньо просто відкрити шкідливу веб-сторінку. (Researchers say they can spy on your browsing by ...)
Суть атаки полягає у використанні API OPFS (Origin Private File System) — механізму браузерів, який дозволяє сайтам зберігати файли локально без окремого запиту дозволу.
JavaScript-код на сторінці створює великий файл у сховищі браузера та постійно вимірює затримки читання з SSD. Коли користувач відкриває інші сайти або програми, активність накопичувача змінюється. Ці коливання аналізуються нейромережею, яка може «впізнавати» шаблони роботи конкретних сайтів чи застосунків. (Researchers say they can spy on your browsing by ...)
У тестах на MacBook з Apple M2 дослідники змогли:
• визначати відкриті вебсайти з точністю близько 89%;
• визначати запущені програми з точністю близько 96%. (Researchers say they can spy on your browsing by ...)
Особливо неприємним є те, що це — ще один приклад так званих side-channel attacks (атак через побічні канали), де витік даних відбувається не через баг у логіці браузера, а через непрямі фізичні характеристики системи — у цьому випадку затримки доступу до SSD.
Дослідники зазначають, що атака має обмеження:
• OPFS-файл повинен бути дуже великим (ймовірно понад 1 ГБ);
• метод працює лише для того SSD, де розташований браузер;
• наразі немає підтверджень використання FROST у реальних атаках. (Websites have a new way to spy on visitors: analyzing their ...)
Втім, сама поява такого методу показує, наскільки складно сучасним браузерам гарантувати приватність. Навіть ізольовані API та sandbox-механізми можуть створювати нові канали витоку інформації.
Це також не перший випадок подібних атак. Раніше дослідники вже демонстрували різні варіанти history sniffing — методів, які дозволяють сайтам дізнаватися про активність користувача через непрямі ознаки роботи браузера. (History sniffing)
Метод отримав назву FROST (Fingerprinting Remotely using OPFS-based SSD Timing). Його описали дослідники з Технічного університету Граца (Австрія). Атака не потребує дозволів, встановлення ПЗ чи взаємодії з боку жертви — достатньо просто відкрити шкідливу веб-сторінку. (Researchers say they can spy on your browsing by ...)
Суть атаки полягає у використанні API OPFS (Origin Private File System) — механізму браузерів, який дозволяє сайтам зберігати файли локально без окремого запиту дозволу.
JavaScript-код на сторінці створює великий файл у сховищі браузера та постійно вимірює затримки читання з SSD. Коли користувач відкриває інші сайти або програми, активність накопичувача змінюється. Ці коливання аналізуються нейромережею, яка може «впізнавати» шаблони роботи конкретних сайтів чи застосунків. (Researchers say they can spy on your browsing by ...)
У тестах на MacBook з Apple M2 дослідники змогли:
• визначати відкриті вебсайти з точністю близько 89%;
• визначати запущені програми з точністю близько 96%. (Researchers say they can spy on your browsing by ...)
Особливо неприємним є те, що це — ще один приклад так званих side-channel attacks (атак через побічні канали), де витік даних відбувається не через баг у логіці браузера, а через непрямі фізичні характеристики системи — у цьому випадку затримки доступу до SSD.
Дослідники зазначають, що атака має обмеження:
• OPFS-файл повинен бути дуже великим (ймовірно понад 1 ГБ);
• метод працює лише для того SSD, де розташований браузер;
• наразі немає підтверджень використання FROST у реальних атаках. (Websites have a new way to spy on visitors: analyzing their ...)
Втім, сама поява такого методу показує, наскільки складно сучасним браузерам гарантувати приватність. Навіть ізольовані API та sandbox-механізми можуть створювати нові канали витоку інформації.
Це також не перший випадок подібних атак. Раніше дослідники вже демонстрували різні варіанти history sniffing — методів, які дозволяють сайтам дізнаватися про активність користувача через непрямі ознаки роботи браузера. (History sniffing)
Tom's Hardware
Researchers say they can spy on your browsing by measuring SSD activity through a browser API — claim FROST attack requires no…
The technique correctly identified visited websites with roughly 89% accuracy and running applications with roughly 96% accuracy on a test Mac
🔥2👍1
🔐 Google Chrome отримує захист від викрадення сесій
Google почала розгортати для всіх користувачів Chrome новий механізм безпеки під назвою Device Bound Session Credentials (DBSC), який має ускладнити один із найпоширеніших способів захоплення акаунтів — викрадення сесійних cookie-файлів.
Зазвичай після входу на сайт браузер зберігає спеціальний токен сесії (cookie). Якщо шкідливе ПЗ або інфостілер викрадає цей токен, зловмисник може отримати доступ до акаунта без пароля та навіть без повторного проходження двофакторної автентифікації. Саме тому продаж викрадених сесій давно став окремим кримінальним бізнесом.
Нова технологія DBSC прив'язує сесію не лише до браузера, а й до конкретного пристрою. Для цього використовуються апаратні модулі безпеки:
• TPM у Windows;
• Secure Enclave у macOS.
Ключі для підтвердження сесії генеруються всередині цих захищених модулів і не можуть бути експортовані. У результаті навіть якщо malware викраде cookie, використати його на іншому комп'ютері буде значно складніше або неможливо.
Google заявляє, що DBSC переводить захист від викрадення сесій від моделі «виявити атаку після факту» до моделі «не дати використати викрадені дані взагалі». Технологія вже доступна в Chrome 146 та поступово розгортається для користувачів.
Втім, це не означає повну перемогу над інфостілерами. Такі шкідники часто крадуть не лише cookie, а й паролі, токени, SSH-ключі, конфігурації VPN та інші дані. Тому оновлення Chrome підвищує безпеку, але не скасовує необхідності використовувати антивірусний захист, оновлювати систему та обережно ставитися до запуску стороннього ПЗ.
#безпека #google #chrome #cybersecurity #privacy #infostealer
Google почала розгортати для всіх користувачів Chrome новий механізм безпеки під назвою Device Bound Session Credentials (DBSC), який має ускладнити один із найпоширеніших способів захоплення акаунтів — викрадення сесійних cookie-файлів.
Зазвичай після входу на сайт браузер зберігає спеціальний токен сесії (cookie). Якщо шкідливе ПЗ або інфостілер викрадає цей токен, зловмисник може отримати доступ до акаунта без пароля та навіть без повторного проходження двофакторної автентифікації. Саме тому продаж викрадених сесій давно став окремим кримінальним бізнесом.
Нова технологія DBSC прив'язує сесію не лише до браузера, а й до конкретного пристрою. Для цього використовуються апаратні модулі безпеки:
• TPM у Windows;
• Secure Enclave у macOS.
Ключі для підтвердження сесії генеруються всередині цих захищених модулів і не можуть бути експортовані. У результаті навіть якщо malware викраде cookie, використати його на іншому комп'ютері буде значно складніше або неможливо.
Google заявляє, що DBSC переводить захист від викрадення сесій від моделі «виявити атаку після факту» до моделі «не дати використати викрадені дані взагалі». Технологія вже доступна в Chrome 146 та поступово розгортається для користувачів.
Втім, це не означає повну перемогу над інфостілерами. Такі шкідники часто крадуть не лише cookie, а й паролі, токени, SSH-ключі, конфігурації VPN та інші дані. Тому оновлення Chrome підвищує безпеку, але не скасовує необхідності використовувати антивірусний захист, оновлювати систему та обережно ставитися до запуску стороннього ПЗ.
#безпека #google #chrome #cybersecurity #privacy #infostealer
BleepingComputer
Google Chrome adds session cookie theft protection for all users
Google says the Chrome Device Bound Session Credentials (DBSC) security feature is now generally available and is rolling out to all users to prevent account takeovers.
👍3
Хакери навчилися маскувати malware не під “зламаний Photoshop”, а під звичайний AI/dev workflow.
Нещодавно зловмисники просували через Google Ads фейкову інструкцію для Claude на macOS.
Схема виглядала максимально буденно:
— користувач шукає щось типу
— Google показує рекламне посилання на
— сторінка виглядає легітимною;
— інструкція містить “звичайні” terminal-команди;
— фінальна команда запускає base64-кодований payload із malware.
Найцікавіше тут навіть не сам вірус.
А те, як змінилася модель атак.
Раніше phishing виглядав як:
— дивний сайт;
— кривий дизайн;
— .exe з торента;
— лист від “банку”.
Тепер атака виглядає як нормальний onboarding для AI-інструменту:
— справжній домен;
— справжня реклама Google;
— знайомі shell-команди;
— типовий dev workflow.
І це вже проблема не “неуважних користувачів”.
Сучасна культура розробки буквально нормалізувала:
та сліпий copy-paste команд із:
— документацій;
— GitHub;
— Stack Overflow;
— AI-асистентів.
Base64 тут теж не “магія хакерів”, а банальний спосіб сховати payload у довгій команді, яку майже ніхто не читає.
Головний висновок:
безпека у 2026 році — це вже не “не відкривай підозрілий exe”.
Це:
— перевірка команд перед запуском;
— недовіра навіть до “легітимних” workflow;
— розуміння, що Google/AI/відомий бренд ≠ гарантія безпеки.
Shell-команди стали новою формою соціальної інженерії.
Нещодавно зловмисники просували через Google Ads фейкову інструкцію для Claude на macOS.
Схема виглядала максимально буденно:
— користувач шукає щось типу
brew macos;— Google показує рекламне посилання на
claude.ai;— сторінка виглядає легітимною;
— інструкція містить “звичайні” terminal-команди;
— фінальна команда запускає base64-кодований payload із malware.
Найцікавіше тут навіть не сам вірус.
А те, як змінилася модель атак.
Раніше phishing виглядав як:
— дивний сайт;
— кривий дизайн;
— .exe з торента;
— лист від “банку”.
Тепер атака виглядає як нормальний onboarding для AI-інструменту:
— справжній домен;
— справжня реклама Google;
— знайомі shell-команди;
— типовий dev workflow.
І це вже проблема не “неуважних користувачів”.
Сучасна культура розробки буквально нормалізувала:
curl ... | bash
та сліпий copy-paste команд із:
— документацій;
— GitHub;
— Stack Overflow;
— AI-асистентів.
Base64 тут теж не “магія хакерів”, а банальний спосіб сховати payload у довгій команді, яку майже ніхто не читає.
Головний висновок:
безпека у 2026 році — це вже не “не відкривай підозрілий exe”.
Це:
— перевірка команд перед запуском;
— недовіра навіть до “легітимних” workflow;
— розуміння, що Google/AI/відомий бренд ≠ гарантія безпеки.
Shell-команди стали новою формою соціальної інженерії.
👍2
🔥 Meta AI сама віддала хакерам доступ до чужих Instagram-акаунтів
Черговий приклад того, чому автоматизація критично важливих процесів за допомогою ШІ може закінчитися дуже погано.
Журналісти 404 Media повідомили, що хакери змогли захоплювати Instagram-акаунти, просто попросивши AI-помічника підтримки Meta змінити прив'язану електронну пошту облікового запису. Після цього вони отримували можливість скинути пароль і повністю перехопити контроль над акаунтом.
За даними дослідників і журналістів, серед постраждалих опинилися акаунти з гучними іменами, включаючи архівний акаунт Білого дому часів Барака Обами, акаунт головного сержанта Космічних сил США та сторінку Sephora.
Схема атаки виглядала майже абсурдно просто:
• хакер звертався до AI-бота підтримки Meta;
• просив прив'язати нову електронну адресу до чужого акаунта;
• бот надсилав код підтвердження на адресу, яку вказав сам зловмисник;
• після введення коду бот пропонував скинути пароль;
• акаунт переходив під контроль нападника.
Фактично система довіряла людині по той бік чату без належної перевірки особи. Деякі повідомлення вказують, що для підвищення шансів успіху зловмисники також використовували VPN, щоб виглядати як користувач із того ж регіону, що й жертва.
Meta вже підтвердила проблему та заявила, що вразливість виправлено. Компанія стверджує, що зламу внутрішніх систем не було, а проблема стосувалася механізму роботи AI-підтримки.
📌 Головний висновок цієї історії: небезпека ШІ часто полягає не в тому, що він надто розумний, а в тому, що йому дають надто багато повноважень без належних запобіжників.
Якщо AI може змінювати прив'язані адреси електронної пошти, скидати паролі або виконувати інші критичні дії, будь-яка помилка в логіці перевірки особи перетворюється на готовий інструмент для захоплення акаунтів.
#безпека #meta #instagram #ai #кібербезпека #osint #ші #хакери
Черговий приклад того, чому автоматизація критично важливих процесів за допомогою ШІ може закінчитися дуже погано.
Журналісти 404 Media повідомили, що хакери змогли захоплювати Instagram-акаунти, просто попросивши AI-помічника підтримки Meta змінити прив'язану електронну пошту облікового запису. Після цього вони отримували можливість скинути пароль і повністю перехопити контроль над акаунтом.
За даними дослідників і журналістів, серед постраждалих опинилися акаунти з гучними іменами, включаючи архівний акаунт Білого дому часів Барака Обами, акаунт головного сержанта Космічних сил США та сторінку Sephora.
Схема атаки виглядала майже абсурдно просто:
• хакер звертався до AI-бота підтримки Meta;
• просив прив'язати нову електронну адресу до чужого акаунта;
• бот надсилав код підтвердження на адресу, яку вказав сам зловмисник;
• після введення коду бот пропонував скинути пароль;
• акаунт переходив під контроль нападника.
Фактично система довіряла людині по той бік чату без належної перевірки особи. Деякі повідомлення вказують, що для підвищення шансів успіху зловмисники також використовували VPN, щоб виглядати як користувач із того ж регіону, що й жертва.
Meta вже підтвердила проблему та заявила, що вразливість виправлено. Компанія стверджує, що зламу внутрішніх систем не було, а проблема стосувалася механізму роботи AI-підтримки.
📌 Головний висновок цієї історії: небезпека ШІ часто полягає не в тому, що він надто розумний, а в тому, що йому дають надто багато повноважень без належних запобіжників.
Якщо AI може змінювати прив'язані адреси електронної пошти, скидати паролі або виконувати інші критичні дії, будь-яка помилка в логіці перевірки особи перетворюється на готовий інструмент для захоплення акаунтів.
#безпека #meta #instagram #ai #кібербезпека #osint #ші #хакери
404 Media
Hackers Simply Asked Meta AI to Give Them Access to High-Profile Instagram Accounts. It Worked
The exploit shows the extreme risk of offloading technical support to AI.
👍1🔥1
🚨 Фейковий репозиторій OpenAI став №1 у трендах Hugging Face — і розповсюджував malware
Зловмисники створили підроблений репозиторій
За кілька днів він вийшов у топ Hugging Face та набрав близько 244 000 завантажень. (The Hacker News)
📌 Що сталося:
— репозиторій копіював опис і структуру справжнього проєкту OpenAI;
— всередині знаходився
— malware викрадав:
• паролі браузерів
• Discord-токени
• SSH-ключі
• VPN-дані
• crypto-wallet credentials. (Decrypt)
Дослідники з HiddenLayer повідомили, що атака була типовим typosquatting: фейковий namespace виглядав майже ідентично до офіційного OpenAI-репозиторію. (The Hacker News)
⚠️ Найнебезпечніше тут навіть не malware, а те, наскільки легко AI-екосистема стала новою supply-chain ціллю:
сьогодні розробники без перевірки запускають
І цього вже достатньо для компрометації системи.
💬 Висновок:
Ера “open-source AI = safe by default” закінчується.
Тепер перевіряти потрібно не лише пакети з PyPI/npm, а й Hugging Face, GitHub-моделі та AI demo-репозиторії.
#AI #CyberSecurity #OpenAI #HuggingFace #Malware #InfoSec #SupplyChainAttack
Зловмисники створили підроблений репозиторій
Open-OSS/privacy-filter, який маскувався під офіційну модель OpenAI Privacy Filter.За кілька днів він вийшов у топ Hugging Face та набрав близько 244 000 завантажень. (The Hacker News)
📌 Що сталося:
— репозиторій копіював опис і структуру справжнього проєкту OpenAI;
— всередині знаходився
loader.py, який запускав багаторівневий infostealer;— malware викрадав:
• паролі браузерів
• Discord-токени
• SSH-ключі
• VPN-дані
• crypto-wallet credentials. (Decrypt)
Дослідники з HiddenLayer повідомили, що атака була типовим typosquatting: фейковий namespace виглядав майже ідентично до офіційного OpenAI-репозиторію. (The Hacker News)
⚠️ Найнебезпечніше тут навіть не malware, а те, наскільки легко AI-екосистема стала новою supply-chain ціллю:
сьогодні розробники без перевірки запускають
pip install, loader.py або готові AI-моделі просто з трендів.І цього вже достатньо для компрометації системи.
💬 Висновок:
Ера “open-source AI = safe by default” закінчується.
Тепер перевіряти потрібно не лише пакети з PyPI/npm, а й Hugging Face, GitHub-моделі та AI demo-репозиторії.
#AI #CyberSecurity #OpenAI #HuggingFace #Malware #InfoSec #SupplyChainAttack
GitHub
GitHub - openai/privacy-filter: OpenAI Privacy Filter
OpenAI Privacy Filter. Contribute to openai/privacy-filter development by creating an account on GitHub.
👍2
📦 Flathub оголосив війну ШІ-коду: AI-згенеровані застосунки більше не прийматимуть
Найбільший каталог Flatpak-застосунків для Linux — Flathub — суттєво посилив свою політику щодо генеративного ШІ. Відтепер платформа прямо забороняє публікацію застосунків, які містять AI-згенерований або AI-асистований код, документацію чи інший контент.
Під заборону потрапляє не лише сам код програми, а й практично весь процес подання:
• вихідний код застосунку;
• документація;
• Flatpak-маніфести;
• build-скрипти;
• метадані;
• навіть тексти pull request та автоматичні AI-рев'ю.
За порушення правил заявку можуть відхилити без розгляду, а повторні порушення можуть призвести до повної заборони на подальші публікації у Flathub.
Причиною такого рішення стала хвиля низькоякісних застосунків, створених за допомогою так званого «vibe coding», а також зростання навантаження на модераторів. Один із супроводжувачів Flathub, Барт Пйотровський, заявив, що останнім часом зіткнувся з великою кількістю конфліктних ситуацій із авторами AI-згенерованих проєктів, після чого вирішив підтримати жорсткіші правила.
Втім, у політиці залишили невеликий виняток: для окремих зрілих та добре підтримуваних проєктів можуть бути зроблені виключення, хоча критерії таких винятків наразі не розкриваються.
Це один із найрадикальніших кроків у Linux-спільноті щодо генеративного ШІ. На відміну від багатьох інших проєктів, які намагаються регулювати використання ШІ, Flathub фактично обрав модель «спочатку заборонити, потім розглядати винятки».
#linux #flathub #flatpak #opensource #ai #chatgpt #copilot #кібербезпека #ші
Найбільший каталог Flatpak-застосунків для Linux — Flathub — суттєво посилив свою політику щодо генеративного ШІ. Відтепер платформа прямо забороняє публікацію застосунків, які містять AI-згенерований або AI-асистований код, документацію чи інший контент.
Під заборону потрапляє не лише сам код програми, а й практично весь процес подання:
• вихідний код застосунку;
• документація;
• Flatpak-маніфести;
• build-скрипти;
• метадані;
• навіть тексти pull request та автоматичні AI-рев'ю.
За порушення правил заявку можуть відхилити без розгляду, а повторні порушення можуть призвести до повної заборони на подальші публікації у Flathub.
Причиною такого рішення стала хвиля низькоякісних застосунків, створених за допомогою так званого «vibe coding», а також зростання навантаження на модераторів. Один із супроводжувачів Flathub, Барт Пйотровський, заявив, що останнім часом зіткнувся з великою кількістю конфліктних ситуацій із авторами AI-згенерованих проєктів, після чого вирішив підтримати жорсткіші правила.
Втім, у політиці залишили невеликий виняток: для окремих зрілих та добре підтримуваних проєктів можуть бути зроблені виключення, хоча критерії таких винятків наразі не розкриваються.
Це один із найрадикальніших кроків у Linux-спільноті щодо генеративного ШІ. На відміну від багатьох інших проєктів, які намагаються регулювати використання ШІ, Flathub фактично обрав модель «спочатку заборонити, потім розглядати винятки».
#linux #flathub #flatpak #opensource #ai #chatgpt #copilot #кібербезпека #ші
❤1👍1
⚠️ Масова атака на WordPress: критична вразливість у WP Maps Pro вже використовується хакерами
Кіберзлочинці активно атакують WordPress-сайти через критичну вразливість CVE-2026-8732 у популярному плагіні WP Maps Pro. Проблема отримала максимальну оцінку небезпеки — 9,8 бала з 10 за шкалою CVSS.
Уразливість дозволяє будь-кому без авторизації створити обліковий запис адміністратора, а потім увійти на сайт із повними правами керування. Фактично це означає повне захоплення WordPress-ресурсу.
Проблема пов'язана з механізмом «тимчасового доступу» для технічної підтримки. Через помилки в реалізації зловмисники можуть викликати спеціальний AJAX-запит і отримати «магічне» посилання для входу під новоствореним адміністратором без пароля.
За даними дослідників, лише за одну добу системи захисту зафіксували та заблокували від 2 800 до понад 3 600 спроб експлуатації цієї вразливості. Атаки вже відбуваються в реальному світі, а не лише в лабораторних умовах.
🔍 Уразливими є всі версії WP Maps Pro до 6.1.0 включно. Виправлення випущено у версії 6.1.1, і власникам сайтів рекомендують оновитися негайно.
Якщо ваш сайт використовує WP Maps Pro:
• негайно перевірте версію плагіна;
• оновіть його до 6.1.1 або новішої;
• перевірте список адміністраторів на наявність невідомих акаунтів;
• перегляньте журнали входу та активності за останні дні.
WordPress залишається найпопулярнішою CMS у світі, а тому будь-яка критична вразливість у популярному плагіні швидко перетворюється на масову хвилю атак. Цього разу під загрозою опинилися понад 15 тисяч сайтів, що використовують WP Maps Pro.
#безпека #wordpress #cve20268732 #cybersecurity #infosec #wordpresssecurity #hacking #wpmapspro
Кіберзлочинці активно атакують WordPress-сайти через критичну вразливість CVE-2026-8732 у популярному плагіні WP Maps Pro. Проблема отримала максимальну оцінку небезпеки — 9,8 бала з 10 за шкалою CVSS.
Уразливість дозволяє будь-кому без авторизації створити обліковий запис адміністратора, а потім увійти на сайт із повними правами керування. Фактично це означає повне захоплення WordPress-ресурсу.
Проблема пов'язана з механізмом «тимчасового доступу» для технічної підтримки. Через помилки в реалізації зловмисники можуть викликати спеціальний AJAX-запит і отримати «магічне» посилання для входу під новоствореним адміністратором без пароля.
За даними дослідників, лише за одну добу системи захисту зафіксували та заблокували від 2 800 до понад 3 600 спроб експлуатації цієї вразливості. Атаки вже відбуваються в реальному світі, а не лише в лабораторних умовах.
🔍 Уразливими є всі версії WP Maps Pro до 6.1.0 включно. Виправлення випущено у версії 6.1.1, і власникам сайтів рекомендують оновитися негайно.
Якщо ваш сайт використовує WP Maps Pro:
• негайно перевірте версію плагіна;
• оновіть його до 6.1.1 або новішої;
• перевірте список адміністраторів на наявність невідомих акаунтів;
• перегляньте журнали входу та активності за останні дні.
WordPress залишається найпопулярнішою CMS у світі, а тому будь-яка критична вразливість у популярному плагіні швидко перетворюється на масову хвилю атак. Цього разу під загрозою опинилися понад 15 тисяч сайтів, що використовують WP Maps Pro.
#безпека #wordpress #cve20268732 #cybersecurity #infosec #wordpresssecurity #hacking #wpmapspro
👍2
🔐 Google закрила 124 вразливості Android. Серед них — zero-day, який вже використовували в атаках
Google випустила червневий пакет оновлень безпеки для Android, усунувши 124 вразливості, включаючи небезпечну CVE-2025-48595, яка, за даними компанії, вже використовувалася у «обмежених та цілеспрямованих атаках».
Уразливість знаходилася в компоненті Android Framework та дозволяла зловмиснику з локальним доступом до пристрою отримати підвищені привілеї та виконувати код із розширеними правами. Особливо ризикували пристрої на Android 14 і новіших версіях.
Подібні помилки традиційно становлять особливий інтерес не лише для кіберзлочинців, а й для державних спецслужб та розробників шпигунського ПЗ. Після отримання початкового доступу до смартфона такі вразливості можуть використовуватися для обходу обмежень системи, встановлення шпигунських модулів або отримання доступу до конфіденційних даних. ([Forbes][3])
Google не розкриває деталей атак, але офіційно підтверджує наявність ознак експлуатації CVE-2025-48595 «у дикій природі».
📱 Що робити користувачам?
• Встановити останні оновлення безпеки Android.
• Не відкладати оновлення системи навіть якщо пристрій працює стабільно.
• Бути особливо обережними з встановленням програм із сторонніх джерел.
Якщо ваш смартфон досі не отримує оновлення безпеки від виробника, це ще одне нагадування про те, наскільки важливою є підтримка пристрою після його покупки.
#безпека #android #google #кібербезпека #zeroday #вразливості #privacy #mobilesecurity
Google випустила червневий пакет оновлень безпеки для Android, усунувши 124 вразливості, включаючи небезпечну CVE-2025-48595, яка, за даними компанії, вже використовувалася у «обмежених та цілеспрямованих атаках».
Уразливість знаходилася в компоненті Android Framework та дозволяла зловмиснику з локальним доступом до пристрою отримати підвищені привілеї та виконувати код із розширеними правами. Особливо ризикували пристрої на Android 14 і новіших версіях.
Подібні помилки традиційно становлять особливий інтерес не лише для кіберзлочинців, а й для державних спецслужб та розробників шпигунського ПЗ. Після отримання початкового доступу до смартфона такі вразливості можуть використовуватися для обходу обмежень системи, встановлення шпигунських модулів або отримання доступу до конфіденційних даних. ([Forbes][3])
Google не розкриває деталей атак, але офіційно підтверджує наявність ознак експлуатації CVE-2025-48595 «у дикій природі».
📱 Що робити користувачам?
• Встановити останні оновлення безпеки Android.
• Не відкладати оновлення системи навіть якщо пристрій працює стабільно.
• Бути особливо обережними з встановленням програм із сторонніх джерел.
Якщо ваш смартфон досі не отримує оновлення безпеки від виробника, це ще одне нагадування про те, наскільки важливою є підтримка пристрою після його покупки.
#безпека #android #google #кібербезпека #zeroday #вразливості #privacy #mobilesecurity
BleepingComputer
Google fixes one actively exploited Android zero-day, 124 flaws
Google has released the June 2026 Android security patches to address 124 vulnerabilities, including one zero-day flaw exploited in targeted attacks.
👍1🔥1
⚠️ Уразливість у OpenAI Codex дозволяла викрадати GitHub-токени розробників
Дослідники з компанії BeyondTrust виявили критичну уразливість у OpenAI Codex, яка дозволяла зловмисникам викрадати GitHub-токени розробників через атаку типу command injection. Проблема була пов'язана з недостатньою перевіркою назв GitHub-гілок (branch names), які могли містити приховані шкідливі команди.
Сценарій атаки виглядав особливо небезпечно: достатньо було створити спеціально сформовану гілку в репозиторії. Під час роботи Codex міг виконати вбудовані команди всередині свого контейнера, після чого GitHub OAuth-токени користувача передавалися на сервер атакуючого. Уразливість зачіпала не лише веб-версію Codex, а й CLI, SDK та інтеграції з IDE.
Дослідники також продемонстрували техніку приховування шкідливого навантаження за допомогою спеціальних Unicode-символів, через що атака могла залишатися практично непомітною для людини.
OpenAI виправила проблему після відповідального розкриття інформації. Компанія посилила перевірку вхідних даних, покращила захист від командної ін'єкції та обмежила доступність токенів усередині середовища виконання.
Окремо варто згадати ще одну нещодавню знахідку дослідників: npm-пакет «codexui-android», який позиціонувався як зручний веб-інтерфейс для OpenAI Codex, протягом кількох тижнів непомітно викрадав токени автентифікації користувачів. Особливо небезпечним був refresh token, який дозволяв довгостроково видавати себе за жертву.
🔐 Висновок простий: AI-агенти для програмування вже отримують доступ до репозиторіїв, токенів та інфраструктури розробників. Їх варто розглядати не як «розумні підказки», а як повноцінні привілейовані компоненти, які потребують такого ж контролю безпеки, як CI/CD-системи або корпоративні сервери.
Дослідники з компанії BeyondTrust виявили критичну уразливість у OpenAI Codex, яка дозволяла зловмисникам викрадати GitHub-токени розробників через атаку типу command injection. Проблема була пов'язана з недостатньою перевіркою назв GitHub-гілок (branch names), які могли містити приховані шкідливі команди.
Сценарій атаки виглядав особливо небезпечно: достатньо було створити спеціально сформовану гілку в репозиторії. Під час роботи Codex міг виконати вбудовані команди всередині свого контейнера, після чого GitHub OAuth-токени користувача передавалися на сервер атакуючого. Уразливість зачіпала не лише веб-версію Codex, а й CLI, SDK та інтеграції з IDE.
Дослідники також продемонстрували техніку приховування шкідливого навантаження за допомогою спеціальних Unicode-символів, через що атака могла залишатися практично непомітною для людини.
OpenAI виправила проблему після відповідального розкриття інформації. Компанія посилила перевірку вхідних даних, покращила захист від командної ін'єкції та обмежила доступність токенів усередині середовища виконання.
Окремо варто згадати ще одну нещодавню знахідку дослідників: npm-пакет «codexui-android», який позиціонувався як зручний веб-інтерфейс для OpenAI Codex, протягом кількох тижнів непомітно викрадав токени автентифікації користувачів. Особливо небезпечним був refresh token, який дозволяв довгостроково видавати себе за жертву.
🔐 Висновок простий: AI-агенти для програмування вже отримують доступ до репозиторіїв, токенів та інфраструктури розробників. Їх варто розглядати не як «розумні підказки», а як повноцінні привілейовані компоненти, які потребують такого ж контролю безпеки, як CI/CD-системи або корпоративні сервери.
👍2
🔥 Чи не занадто особистою є боротьба з Telegram?
Співголова фракції «Європейська Солідарність» Артур Герасимов є одним із найактивніших прихильників посилення контролю над Telegram та деанонімізації авторів каналів. Саме фракція «ЄС» останніми місяцями наполягала на розгляді відповідних законодавчих ініціатив у Верховній Раді.
Втім, виникає логічне питання: чи не пов'язана така активність із тим, що сам Герасимов неодноразово ставав об'єктом резонансних публікацій щодо своїх статків та нерухомості?
Нагадаємо:
▪️ НАЗК розпочинало моніторинг способу життя нардепа після журналістських розслідувань щодо користування елітним майном.
▪️ НАБУ та САП повідомляли йому про підозру у справі щодо недостовірного декларування нерухомості в Іспанії.
▪️ Судова справа стосувалася невнесення до декларації іспанської вілли та паркомісця вартістю понад 250 тисяч євро.
Безумовно, Telegram має чимало проблем — від шахрайства до дезінформації. Але коли політик, щодо якого існували гучні розслідування та питання до декларацій, одночасно вимагає обмежити анонімність платформи, яка стала одним із головних майданчиків для викриттів, суспільство має право ставити незручні питання.
Чи йдеться про турботу про безпеку держави? Чи про бажання зробити менш комфортним життя тим, хто публікує незручну інформацію про політиків?
Відповідь на це питання кожен може зробити сам.
#telegram #герасимов #єс #корупція #декларації #україна
Співголова фракції «Європейська Солідарність» Артур Герасимов є одним із найактивніших прихильників посилення контролю над Telegram та деанонімізації авторів каналів. Саме фракція «ЄС» останніми місяцями наполягала на розгляді відповідних законодавчих ініціатив у Верховній Раді.
Втім, виникає логічне питання: чи не пов'язана така активність із тим, що сам Герасимов неодноразово ставав об'єктом резонансних публікацій щодо своїх статків та нерухомості?
Нагадаємо:
▪️ НАЗК розпочинало моніторинг способу життя нардепа після журналістських розслідувань щодо користування елітним майном.
▪️ НАБУ та САП повідомляли йому про підозру у справі щодо недостовірного декларування нерухомості в Іспанії.
▪️ Судова справа стосувалася невнесення до декларації іспанської вілли та паркомісця вартістю понад 250 тисяч євро.
Безумовно, Telegram має чимало проблем — від шахрайства до дезінформації. Але коли політик, щодо якого існували гучні розслідування та питання до декларацій, одночасно вимагає обмежити анонімність платформи, яка стала одним із головних майданчиків для викриттів, суспільство має право ставити незручні питання.
Чи йдеться про турботу про безпеку держави? Чи про бажання зробити менш комфортним життя тим, хто публікує незручну інформацію про політиків?
Відповідь на це питання кожен може зробити сам.
#telegram #герасимов #єс #корупція #декларації #україна
❤1👍1
⚠️ У Telegram підтвердили витік службового ідентифікатора користувача
Компанія Symbolic Software опублікувала результати незалежного аналізу протоколу Telegram MTProto та підтвердила проблему, про яку раніше повідомляли журналісти OCCRP та «Важные истории».
Дослідники встановили, що Telegram передає службовий ідентифікатор
Що це означає на практиці?
🔹 Інтернет-провайдери, адміністратори мереж або державні системи моніторингу можуть збирати ці ідентифікатори шляхом пасивного спостереження за трафіком.
🔹 Отриманий
🔹 Для збору таких даних не потрібно проводити атаку типу Man-in-the-Middle або зламувати сертифікати — достатньо доступу до мережевого трафіку.
Важливий нюанс: наразі немає підтверджень, що ця проблема сама по собі дозволяє читати повідомлення користувачів. Підтверджений ризик стосується саме витоку метаданих та потенційної деанонімізації.
Експерти Symbolic Software заявили, що проблема пов'язана не з окремою помилкою в коді, а з архітектурними рішеннями Telegram щодо захисту транспортного рівня.
📌 Чергове нагадування: Telegram не варто розглядати як месенджер для конфіденційного спілкування. Для чутливих комунікацій краще використовувати месенджери з наскрізним шифруванням за замовчуванням, де навіть метадані максимально захищені.
#telegram #privacy #security #mtproto #кібербезпека
Компанія Symbolic Software опублікувала результати незалежного аналізу протоколу Telegram MTProto та підтвердила проблему, про яку раніше повідомляли журналісти OCCRP та «Важные истории».
Дослідники встановили, що Telegram передає службовий ідентифікатор
auth_key_id без належного транспортного шифрування. Цей ідентифікатор є постійним для конкретного пристрою та не змінюється при зміні IP-адреси, мережі чи географічного розташування.Що це означає на практиці?
🔹 Інтернет-провайдери, адміністратори мереж або державні системи моніторингу можуть збирати ці ідентифікатори шляхом пасивного спостереження за трафіком.
🔹 Отриманий
auth_key_id дозволяє відстежувати активність одного й того ж користувача в різних мережах і локаціях.🔹 Для збору таких даних не потрібно проводити атаку типу Man-in-the-Middle або зламувати сертифікати — достатньо доступу до мережевого трафіку.
Важливий нюанс: наразі немає підтверджень, що ця проблема сама по собі дозволяє читати повідомлення користувачів. Підтверджений ризик стосується саме витоку метаданих та потенційної деанонімізації.
Експерти Symbolic Software заявили, що проблема пов'язана не з окремою помилкою в коді, а з архітектурними рішеннями Telegram щодо захисту транспортного рівня.
📌 Чергове нагадування: Telegram не варто розглядати як месенджер для конфіденційного спілкування. Для чутливих комунікацій краще використовувати месенджери з наскрізним шифруванням за замовчуванням, де навіть метадані максимально захищені.
#telegram #privacy #security #mtproto #кібербезпека
👍3