80 Knowbe4 incidents · Eylül 2025 — official updates, affected components, duration and resolution details.
Alan kaydının nedenini tavsiye veremez ve bir düzeltme uygulamak üzerinde çalışıyoruz. statüsü sayfamızda yeni bilgi veya güncellemelerle yayınlamaya devam edeceğiz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda konsol girişini etkileyen bir sorunu araştırıyoruz. Mevcut olduğunda burada daha fazla güncelleme sağlayacağız.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# **Summary** 13 Ekim 2026'da, yaklaşık 14:19 ile 15:05 \(UTC\), tüm bölgelerdeki müşteriler KnowBe4 Güvenlik Farkındalık Eğitimi \ (SAT\) konsoluna giremediler, KnowBe4 Learner Experience ve PhishER konsolu KnowBe4 SAT aracılığıyla. SAML ve şifre girişleri hataları geri döndürür ve KnowBe4 SAT konsolu KnowBe4 platformunda görünmedi. Kullanıcı senkronizasyonu ve eğitim e-postaları dahil olmak üzere bazı arka plan süreçleri de bu süre zarfında başarısız oldu. Olay, kodumuzda başka bir değişiklikle çelişen bir üretim serbest bırakılmasına neden oldu. Serbestleşmeyi yeniden başlattık ve 14:59 ve 15:05 \(UTC\) arasındaki bölgelere giriş yaptık. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi. # **Root Cause** Bir kod dağıtım, uygulama başlangıç süresini hızlandırmak için bir başlangıç yapılandırma değerini kaldırdı. Orijinal değişiklik test edildikten sonra kodumıza eklenen ayrı bir bileşen, bu değişen değer için hesap vermedi. Sonuç olarak, bir kullanıcı kaydı kurtarmak için her girişim, bu kayıtların işaret girişimleri de dahil olmak üzere bir hata yükseltti. # **Müşteri Etkisi** Tüm bölgelerdeki müşteriler SAML veya şifre yoluyla KSAT konsoluna giriş yapamıyorlardı. Ayrıca Learner Experience'a erişemediler ve KnowBe4 SAT konsolu aracılığıyla PhishER konsoluna erişemediler. Yeni kullanıcı yaratımı, kullanıcı senkronizasyonu ve eğitim e-postaları bu süre zarfında başarısız oldu ancak dağıtım tekrarlandıktan sonra otomatik olarak geri alındı. # **Mession and Remediation** Dağıtımın başka bir bileşenin hala gerekli olduğu bir yapılandırma değeri kaldırdığını bulduk. Bu, salıvererek azaltıldı ve tüm bölgelerde doğrudan kontroller ve otomatik testler yoluyla iyileşmeyi doğruladık. Ayrıca kaynak kodumuzdaki orijinal değişikliği tekrar ettik ve bir uyumluluk düzeltmesi içeren bir düzeltme sürümü hazırladık, böylece orijinal gelişme güvenli bir şekilde yeniden başlatılabilir. # **Proventative Measures** Dağıtımlar için ek kod doğrulamaları ve testleri ekliyoruz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
KnowBe4 Email Security Add-in'in hatayı gösteriyoruz "Ek-in KnowBe4 e-posta güvenliği, e-posta göndermesi sırasında bu mesajın gönderilmesini engelliyor." Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Web Add-in gönderme hataları için bir düzeltme yaptık ve sonuçları daha fazla sorun yaşamadığından izlemeliyiz.
Bu olay çözüldü.
Pazartesi, 12 Ekim 2026, yaklaşık 14:25 \ (UTC) Salı, 13 Ekim 2026, yaklaşık 15:07 \(UTC\), Avrupa Önlemleri ve Koruma konusundaki bazı müşteriler Microsoft Outlook'tan e-posta göndermede güçlük çekti. Etkilenen mesajlar gönderilmedi ve KnowBe4 Email Security add-in aşağıdaki hatayı sergiledi: "Ek-in KnowBe4 Email Security bu mesajın gönderilmesini engelliyor." Bu sorun, ek-in versiyonunun serbest bırakılması için nasıl hazırlandığı konusunda bir hataya neden oldu, bu da aynı sürümden iki farklı kopya üretti. Outlook ek-in yüklerken, eşleşmesi gereken bir dizi dosyayı indirin. AB örneklerinde, Outlook bazen her iki kopyadan dosyaları aldı, bu yüzden eklentiyi bitiremedi ve mesaj gönderilmedi. Bazı cihazlar da başarısız indirmeyi kurtardı, bu yüzden hata bu cihazlarda bir düzeltme uygulanana kadar devam etti. Bu sorunu çözmek için ekibimiz AB add-in dosyalarını düzeltti, böylece her müşteri bir eşleştirme seti alır. Daha sonra add-in'in tüm bölgelerine güncellenmiş bir versiyonunu yayınladık, bu da herhangi bir kurtarılmış hataları temizledi. KnowBe4 Email Security add-in, 13 Ekim 2026'da yaklaşık 15:07 \(UTC\) tarafından normal performansa geri döndü. Gelecekte bu tür sorunu önlemek için, ek sürümlerin nasıl hazırlandığını ve yayınlanmasını değiştiriyoruz, böylece her sürüm her zaman aynı dosya setini ve her müşteri aynı anda aynı sürümü alır. Ayrıca add-in'i değiştiriyoruz, böylece ekleme dosyalarının başarısız indirmeleri cihazlar üzerinde kurtarılmıyor. Son olarak, onları daha önce tespit etmek için ek yükleme hataları için uyarı ekliyoruz. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda ABD sunucularımızı önlemek ve korumak için bozulan bir performansı araştırıyoruz.
ABD Önlem örnekleriyle bir sorunu tespit ettik ve bunun bozulan performansa yol açtığını gördük. Bir düzeltme uygulandı ve bu konuyu izlemeye devam edeceğiz.
Bu olay çözüldü.
# **Summary** Pazartesi, 28 Eylül 2026, yaklaşık 16:00 \ (UTC) Çarşamba günü, 30 Eylül 2026'da, yaklaşık 12:35 \(UTC\), bazı müşteriler gecikmiş posta akışı ve geçici sorunlar ABD'nin Önlem ve Koruma örneklerine erişti. 28 Eylül'de izlememiz ağır ağ trafiği gösterdi, her saatin en üst kısmındaki artışlarla. Bazı müşteriler, ABD'nin Ön ve Koruma konsollarının örneklerine erişen sorunları deneyimlemeye başladı. Posta işlemenin başlaması gereken iç görünümler, ve mesajlar sonuç olarak sıralandı. Müşteriler konuyu destek ekibimize bildirdiler ve bir statü sayfası bildirimini yayınladık. Performans daha sonra o gün ABD trafiği azaldı. 29 Eylül'de mühendislerimiz, posta ağ geçidindeki önceki günün verilerini, bağlı oldukları iç hizmetleri ve ağ katmanını inceledi. Mail akış gecikmeleri ve konsol erişim sorunları kısaca geri döndü, sonra ağ trafiği azaldı, aynı modeli 28 Eylül olarak takip etti. 30 Eylül'de, yaklaşık 12:19'dan 12:35 \(UTC\), ekibimiz servis devam ederken ABD ağ hizmetlerinin kapasitesini artırdı. Onların yükü hemen sonra düştü ve önleme ve koruma 30 Eylül 2026'da yaklaşık 12:35 \(UTC\) normal performansa geri döndü. 30 Eylül ve 1 Ekim'de zirve trafiğini takip ettik ve regreces görmedik. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi. # **Root Cause** Bu sorun, ABD posta işlem hizmetlerimiz için trafik idare eden ağ hizmetlerinde kapasite sınırının nedeni oldu. Top trafik sırasında ve özellikle saat başı artışları sırasında, ağ hizmetleri yeterince hızlı işlem yapamazdı. Bu, onları geçen trafik için gecikme ekledi ve bazı bağlantıların düşmesine neden oldu. Bu trafik, posta ağ geçidimizin dağıtım liste üyelerine bakmak için gönderdiği iç talepleri içeriyordu, bu yüzden doğru politikalar uygulanır. Bu istekler sıkı bir zaman sınırına tabidir, böylece yavaş bir görünüm süresi süresiz olarak posta işlemi tutabilir. Ağ hizmetleri bu sınırın ötesinde gecikdiğinde başarısız oldular. Sonuç olarak, posta işlemi yavaşladı ve mesajlar sıralandı. İki faktör sorunu tanımlamak için daha kötü ve daha zor hale getirdi. İlk olarak, bazı iç istekler bu ağ hizmetlerini de kullandı ve kapasite limitinden etkilendi. İkincisi, ağ hizmetleri, hesaplama kullanımları normal olarak bir probleme işaret edecek seviyelere ulaştı. Standart hesaplama izleme ağ saturasyonunu yakalamadı, bu yüzden nedeni daha uzun tespit etti. Kesme hizmeti olmadan kapasite artırmak için güvenli bir yol bulmak da zaman aldı, bu yüzden düzeltme 30 Eylül'de uygulandı. # **Mession and Remediation** ABD ağ hizmetlerinin zirve trafiğini işlemek için yeterli kapasiteye sahip olmadığını bulduk. Bunu, değişim boyunca çalışan hizmet tutmak için kapasitelerini artırarak azalttık. Kapasite artışından sonra, ağ hizmetleri daha fazla sorun olmadan zirve trafiği ele geçirdi. Ayrıca hesaplamanın yalnızca ağ saturasyonunun güvenilir bir işareti olmadığını da bulduk. Hesaplama kullanımına ek olarak ağ sağlık göstergelerini takip etmek için izlememizi genişlettik. Son olarak, iç isteklerin bozulduğunu bulmak zor olduğunu bulduk. İç isteklerin başarısız ve zamanında nerede olduğunu gösteren log ekledik. # **Müşteri Etkisi** 28 Eylül'de zirve ABD trafiği sırasında, bazı müşteriler işlemde gecikmeler yaşadı ve ön ve koruma yoluyla sınırsız ve kesintiye uğradı. Dağıtım listelerine hitap edilen mesajlar, görünümleri tekrar beslendikçe daha yavaş işlenebilir. Bazı müşteriler aynı zamanda ABD konsolunu kullanmak veya kullanmak için sürekli zorluk çekmedi. Her gün ABD trafiği azaldıkça etki kolaylık sağladı ve kuyruklanmış posta bir kez kapasite geri alındı. 30 Eylül’deki değişimden sonra, zirve trafik sırasında daha fazla bozulma görmedik. # **Proventative Measures** Gelecekte bu tür bir sorunu önlemek için, ABD ağ hizmetlerinin kapasitesini artırdık ve hesaplamaya ek olarak ağ sağlık göstergelerini takip etmek için izlememizi genişlettik. Ayrıca görünmez iç taleplere görünürlüğü geliştirmek için oturum ekledik.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Lisanssız performansa yol açan koruma ile ilgili bir sorunu tespit ettik ve mühendislik ekibimiz bir düzeltmeye bakıyor.
Yüksek lisansüstü performansa yol açan koruma ile ilgili bir sorunu tespit ettik. Bir düzeltme uygulandı ve bu konuyu izlemeye devam edeceğiz.
Lisanssız performansa yol açan koruma ve önleme ile ilgili bir sorunu tespit ettik ve mühendislik ekibimiz bir düzeltmeye bakıyor.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
# **Summary** Perşembe günü, 24 Eylül 2026, yaklaşık 17:07 \(UTC\) Cuma, 25 Eylül 2026, yaklaşık 09:16 \ (UTC\), bazı müşteriler ABD koruma ve önleme örneklerini deneyimledi. 24 Eylül'de, e-posta trafiğinde alışılmadık derecede büyük bir artış, ABD posta işlememiz için trafiği idare eden ağ hizmetleri üzerinde devam etti. İzlememiz bizi yaklaşık 17:07 \(UTC\). Bazı müşteriler yükleme sayfaları veya gelişmiş seçenekler olduğunda yavaş veya aralıklı erişim gördü. Erişim tutarsızdı, bu yüzden bazı müşteriler diğer hataları gördüklerinde korumayı kullanabilirdi. ABD örnekleri yavaşladı ve bazı mesajlar gecikti ya da beklenen modrasyonda görünmedi. Performans geliştirmek için ortaya çıktı, bu yüzden 18:39 \(UTC\). Sorun daha sonra tekrar alındı ve müşteriler destek ekibimize yavaşlığı bildirdi. 19:57 \(UTC\), etkilerin daha net hale getirilmesi ve genişletilmesine geri döndük. Ekibimiz, yüksek posta hacmi sübvanse edildiğinde etkilenen sistemleri izledi. Ağ hizmetlerindeki yük normal, posta işleme geri döndü ve posta kuyrukları bir gecede normale döndü. Korumanın normalde yüklendiğini ve bu test mesajlarının tekrar teslim edildiğini doğruladık ve sonra izlemeye devam ettik. Koruma ve Önleme, 25 Eylül'de 09:16 \ (UTC\) tarafından normal performansa geri döndü. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi. # **Root Cause** Bu sorun, e-posta trafiğinde alışılmadık derecede büyük bir artışla neden oldu. Artan hacim, ABD posta işlememiz için trafiği idare eden ağ hizmetleri üzerinde sürekli bir yük yerleştirdi. Bu ağ hizmetleri sabit kapasite sınırları içinde çalışır ve kapasiteleri artış sırasında ölçeklenebilirdi. Çünkü dalgalanmaya dayanamadılar, yavaşladılar ve bazı işleme geçici olarak başarısız oldu. Sonuç olarak, ABD posta işleminde büyük bir posta hacmi sıralandı, bazı sayfalar ve eylemler geri döndü hatalar ve bazı mesajlar gecikti ya da beklenen modrasyonda görünmedi. İki faktör konuyu yönetmek için daha zor hale getirdi. İlk olarak, erişim başarısız bir şekilde başarısız olduğu için, bazı kontroller müşterilerin hataları görmeye devam ederken, doğrulamayı daha zor hale getirmeye devam etti. İkincisi, izlememiz, mevcut yükten daha net bir şekilde ağ hizmetleri üzerinde zirve yükü gösterdi, bu da yükün hala yüksek olup olmadığını gerçek zamanlı yargılamayı daha zorlaştırdı. # **Mession and Remediation** ABD posta işlemesini ele alan ağ hizmetlerinin trafik artışı sırasında sabit kapasite sınırlarına ulaştığını gördük ve kapasiteleri olay sırasında arttırılamadı. Ekibimiz etkilenen sistemleri takip ederken, yüksek posta hacmi sübvanse edildi ve ağ hizmeti yükü normale döndü. Mail işleme sonra geri alındı ve kuyruklanmış posta işlendi. Çünkü konu daha önce tekrarlamadan önce iyileşmeye başlamıştı, olayı çözmeden önce birkaç şekilde iyileşmeyi doğruladık. Korumanın normalde yüklendiğini doğruladık, bu test mesajları ABD posta işlemi aracılığıyla teslim edildi ve bu destek talepleri normal olarak ilerliyordu. Ayrıca bir gecede izlendik ve ABD örneklerinde müşterilerden yeni raporlar almadık. # **Müşteri Etkisi** Bazı müşteriler korumak için yavaş veya aralıklı erişime sahipti ve bazen yükleme sayfaları veya gelişmiş seçenekler olduğunda hataları gördü. ABD örnekleri aracılığıyla posta işlemi koruma ve önleme için gecikmiştir. Bazı durumlarda, mesajlar gecikti ya da beklenen modrasyonda görünmedi. Posta şifreli, şifrelenmiş veya ABD posta işlememiz üzerinden geçtiği gibi ortalanan müşteriler daha büyük etkilenebilirdi. Ekle-in kullanan müşterilerin çoğu posta işleme gecikmelerinden etkilenmedi. Koruma ve konsolları önlemek mevcuttu, ancak bazı konsol eylemleri daha yavaş posta işlemi tarafından etkilendi. # **Proventative Measures** Gelecekte bu tür sorunu önlemek için, e-posta hacminde olağandışı artışların izlenmesimizi geliştiriyoruz. Ayrıca ağ hizmetlerimizdeki mevcut yükü göstermek için izlememizi geliştiriyoruz, sadece zirve değerleri değil. Buna ek olarak, ağ kapasitemizi aniden trafik artışları sırasında daha dinamik bir şekilde ölçeklendirmenin yollarını değerlendiriyoruz ve ABD posta işlemesini işleten ağ altyapısına daha uzun vadeli gelişmeleri değerlendiriyoruz. Aynı zamanda ABD ağ hizmetlerinin kapasitelerini daha sonraki bir olaya yanıt olarak yükselttik (https://status.knowbe4.com/incidents/9wc6rjm8g70v).
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Giriş yapmaya çalışırken kullanıcıların "Access Denied" hata mesajlarını aldık. Sorunu tespit ettik ve bir çözüm uygulamak için çalışıyoruz ve bu sayfayı daha fazla bilgimiz olduğunda güncelleyeceğiz.
Sorun tespit edildi ve bir düzeltme uygulandı ve bu sayfayı daha fazla bilgimiz olduğunda güncelleyeceğiz.
Bu olay başarıyla çözüldü ve tüm sistemler tamamen operasyonel.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Bazı kullanıcıların webform gönderimlerini başarıyla sunamadığı raporlar aldık. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Sorun tespit edildi ve bir düzeltme uygulandı. Daha fazla bilgi ile bir güncelleme buna göre takip edecektir.
Sorun tespit edildi ve bir düzeltme uygulandı ve bu sayfayı daha fazla bilgimiz olduğunda güncelleyeceğiz.
Bu olay başarıyla çözüldü ve tüm sistemler tamamen operasyonel.
Çarşamba günü, 23 Eylül 2026, yaklaşık 08:15'ten 11:18 \(UTC\), bazı müşteriler İngiltere'de Güvenli Webforms örneklerinde yavaşlık ve başarısız form teklifleri yaşadılar. Bu sorun, son bir değişikliği takip eden İngiltere üretim ortamında veritabanı performans sınırlarına neden oldu. Bir veritabanı ayarı da bazı sorguların verimli bir şekilde çalışmasına neden oldu. Sonuç olarak, yanıt süreleri arttı ve bazı form teklifleri başarısız oldu. Bu sorunu çözmek için, ekibimiz geçici olarak sorgu verimliliğini artırmak için veritabanı ayarlarını azaltır ve depolamayı konsolide edindi. Güvenli Webforms, 11:18 \(UTC\) tarafından normal performansa döndü. Bu tür sorunu gelecekte önlemek için, veritabanı bant genişliği için ek izleme ekliyoruz. Ayrıca arka senkronizasyon görevinin verimliliğini geliştiriyoruz. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Kullanıcıların Web Access (Secure Message Portal) aracılığıyla e-posta gönderemeyeceğine dair raporlar aldık, Hata "503 Service Un available" ile. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Bir düzeltme uyguluyoruz ve sonuçları izliyoruz.
Daha fazla sorun için izlemeye devam ediyoruz.
Bu olay başarıyla çözüldü ve tüm sistemler tamamen operasyonel.
Pazartesi günü, 21 Eylül 2026, Salı gününe kadar yaklaşık 08:55'ten 2026 Eylül'ye kadar, yaklaşık 14:30 \(UTC\), bazı kullanıcılar hata yaşadı ve İngiltere'de Web Access \ (Secure Message Portal\) aracılığıyla e-posta göndermediler. Bu olay bir veritabanı güncellemesi sırasında bir yapılandırma hatasına neden oldu, bu da geçici hizmet kesintisine yol açtı. Bu sorunu çözmek için, yapılandırmayı yeniden yaptık ve Web Access 22:30 \(UTC\) tarafından 22 Eylül 2026'da normal performansa geri döndük. Gelecekte bu tür sorunu önlemek için, veritabanı yapılandırmamızı gözden geçiriyoruz ve güncelliyoruz. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Kullanıcıların KSAT'ın DE ve İngiltere örneklerine giremeyeceğine dair raporlar aldık. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Bu olay çözüldü.
# **Summary** 17 Eylül 2026'da, büyük bir kullanıcı grubu bir arka plan işi arşivlendi ve tek sınırsız veritabanı işlemi olarak koştu. Bu işlem çok sayıda kullanıcı sırasını kilitledi, ABD bölgesine aynı masaya yazmaları nedeniyle tekrar giriş yaptı. Bir platform yürütme limitine çarptıktan sonra, iş sona erdi ve 15 dakikalık aralıklarla beş kez tekrarladı ve 75 dakikalık bir kesintiye yol açtı. Sorunu çözmek için, kilitten o çift girişleri dağıttık. Daha sonra giriş değişikliği ile getirilen bir regresyon için bir takip düzeltmesi yaptık ve arşiv işi için de. # ** What Happened** Önceki bir değişiklik, "tüm kullanıcılar" eylemini bir senkronize, zaman boyunca web isteğine sınırsız bir arka plan işine taşıdı. Büyük bir kullanıcı grubu arşivlendiklerinde, bu yeni arka plan işini tetikledi. İş, tüm etkilenen kullanıcı sıralarını tek bir işlemde kilitledi, per-user başına yazar ve taahhüt etmeden önce senkronize edilen bir dış hizmet çağrısı yaptı. Aynı masaya yazılan giriş girişimleri, kilit işin arkasında sıralandı ve ABD kullanıcıları için zamanlandı. İş 15 dakikalık bir platform yürütme sınırına ulaştığında, orta-transaction sona erdi, işlem geri döndü ve iş kuyruğuna kırmızılandı. Bu döngü, 75 dakikalık bir kesintiye yol açan beş kez meydana geldi. Başarısızlık 22:35 \(UTC)'de içsel olarak tespit edildiğinde, bir olay ilan edildi ve bir mühendis cevap vermek için sayfalandı. Kayıt akışının yazma eylemini devre dışı bırakmak yaklaşık 23:44 \(UTC\). Davanın kendisi bir regresyona neden oldu: daha önce yanlış bir şifre olan herhangi bir bölgedeki herhangi bir kullanıcı artık oturum açmadı çünkü başarısız giriş denemeleri için sıfırlar sadece bir veritabanı yazmaya çalıştı. 09:17 \(UTC\) 18 Eylül 2026'da, bu regresyon için düzeltme bölge genelinde dağıtıldı. Orijinal ABD'nin yalnızca arşiv işi konusu 13:45 ile 14:05 arasında iki kez daha yeniden satın alındı (UTC\) kalıcı bir düzeltmeden önce yaklaşık 15:00 \ (UTC\). Olay 18 Eylül 2026'da 19:12 \ (UTC\) tarafından tamamen çözüldü. # **Root Cause** Büyük grup kullanıcı arşivleri için sınırsız, tek-transaction arka plan işi birçok etkilenen satırlarda özel kilitler tuttu, giriş sürecini kendi satır yazını engelliyor. Bu işlemi bir web isteği zamanından uzaklaştırmak ve arka plan işine geçmek için önceki bir değişiklik, süresinde kalan tek sınırı kaldırdı. Platform'un 15 dakikalık infaz sınırı sonra otomatik öldürme-ve-redeliver döngülerini tetikledi ve kilit içeriği beş kez tekrarladı ve 75 dakikalık bir dışlama penceresinden geçti. # **Hazırları ve Davaları Keşfedin Gelen arşiv işleminin çok sayıda etkilenen kullanıcı sıralarını kilitlediğini, diğer tabloyu engellemediğini gördük. Bu, giriş sürecinin etkilenen masadan bağımlılığını ortadan kaldırarak kısa vadede azaltıldı ve sonra arşiv işini düzelterek uzun vadede sabitlendi. Ayrıca, koordinasyonsuz işçinin kilit içeriklenmelerini tespit ettik. Bu, işçi koncurrency'i manuel olarak azaltarak kısa vadede azaltıldı. Bu işleri dengelemek ve serileştirmek için uzun vadeli bir düzeltme planlanmaktadır. Son olarak, giriş ek regresyonun, önceki başarısız girişimlerle kullanıcılar için tüm-bölge giriş başarısızlıklarına neden olduğunu bulduk çünkü sadece bir veritabanı tarafından reddedildi. Bu, tüm bölgelerde dağıtılan ve doğrulanmış bir kod değişikliği ile sabitlendi. # **Proventive Measures** Onlara bağlı olarak büyük grup arşiv operasyonlarımızı geliştiriyoruz, küçük, kararlı toplu işliyor ve veritabanı işlemi dışında dış çağrıları tutuyoruz. Ayrıca, herhangi bir şeyi değiştirmediğini yazmak için belirli bir arka plan çalışanına bir değişiklik kontrol ekledik. Son olarak, veritabanı işlem yaşı için doğrudan uyarılar ekliyoruz ve gecikmeler ek olarak periyodik dolaylı kontrollere ek olarak. # **Müşteri Etkisi ve Kurtarma** Giriş başarısızlıkları ABD bölgesinde yaklaşık 75 dakika sürdü. İki kısa, ABD'nin sadece geri dönüşleri ertesi sabah gerçekleşti ve birkaç dakika içinde manuel olarak temizlendi. Kullanıcı yönetimi gibi bazı yönetim eylemleri de etkilendi. Partner girişleri etkilenmedi. İkinci regresyon yaklaşık 10 saat sürdü ve daha önce bir giriş denemesi başarısız olan kullanıcılar için tüm bölgeleri etkiledi. 18 Eylül öğleden sonra, tüm bölgelerde tam iyileşme doğrulandı ve durum sayfası çözüldü. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi. # **Conclusion** Tek sınırsız bir arka plan işlemi, otomatik bir yeniden deneme mekanizmasıyla birlikte, ABD bölgesinde bir giriş kesintisine neden oldu. Özel tetikleme işi ve yeniden deneme davranışı düzeltildi ve artık rakip yazma yoluna bağlı değildir. Aynı bir regresyon ve iki küçük recurrences her biri saatlerce çözüldü. İşçi koordinasyonu ve veritabanı işlem izlemesi dahil olmak üzere önleyici çalışmalar yukarıda takip edilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Kullanıcıların KSAT'ın ABD örneğine giremeyeceği raporlar aldık. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Bir düzeltme uyguluyoruz ve sonuçları daha fazla sorun yaşanmadığından takip ediyoruz.
KSAT'ın ABD örneğine giremediği kullanıcıların yeni raporları aldık. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Bu olay çözüldü.
# **Summary** 17 Eylül 2026'da, büyük bir kullanıcı grubu bir arka plan işi arşivlendi ve tek sınırsız veritabanı işlemi olarak koştu. Bu işlem çok sayıda kullanıcı sırasını kilitledi, ABD bölgesine aynı masaya yazmaları nedeniyle tekrar giriş yaptı. Bir platform yürütme limitine çarptıktan sonra, iş sona erdi ve 15 dakikalık aralıklarla beş kez tekrarladı ve 75 dakikalık bir kesintiye yol açtı. Sorunu çözmek için, kilitten o çift girişleri dağıttık. Daha sonra giriş değişikliği ile getirilen bir regresyon için bir takip düzeltmesi yaptık ve arşiv işi için de. # ** What Happened** Önceki bir değişiklik, "tüm kullanıcılar" eylemini bir senkronize, zaman boyunca web isteğine sınırsız bir arka plan işine taşıdı. Büyük bir kullanıcı grubu arşivlendiklerinde, bu yeni arka plan işini tetikledi. İş, tüm etkilenen kullanıcı sıralarını tek bir işlemde kilitledi, per-user başına yazar ve taahhüt etmeden önce senkronize edilen bir dış hizmet çağrısı yaptı. Aynı masaya yazılan giriş girişimleri, kilit işin arkasında sıralandı ve ABD kullanıcıları için zamanlandı. İş 15 dakikalık bir platform yürütme sınırına ulaştığında, orta-transaction sona erdi, işlem geri döndü ve iş kuyruğuna kırmızılandı. Bu döngü, 75 dakikalık bir kesintiye yol açan beş kez meydana geldi. Başarısızlık 22:35 \(UTC)'de içsel olarak tespit edildiğinde, bir olay ilan edildi ve bir mühendis cevap vermek için sayfalandı. Kayıt akışının yazma eylemini devre dışı bırakmak yaklaşık 23:44 \(UTC\). Davanın kendisi bir regresyona neden oldu: daha önce yanlış bir şifre olan herhangi bir bölgedeki herhangi bir kullanıcı artık oturum açmadı çünkü başarısız giriş denemeleri için sıfırlar sadece bir veritabanı yazmaya çalıştı. 09:17 \(UTC\) 18 Eylül 2026'da, bu regresyon için düzeltme bölge genelinde dağıtıldı. Orijinal ABD'nin yalnızca arşiv işi konusu 13:45 ile 14:05 arasında iki kez daha yeniden satın alındı (UTC\) kalıcı bir düzeltmeden önce yaklaşık 15:00 \ (UTC\). Olay 18 Eylül 2026'da 19:12 \ (UTC\) tarafından tamamen çözüldü. # **Root Cause** Büyük grup kullanıcı arşivleri için sınırsız, tek-transaction arka plan işi birçok etkilenen satırlarda özel kilitler tuttu, giriş sürecini kendi satır yazını engelliyor. Bu işlemi bir web isteği zamanından uzaklaştırmak ve arka plan işine geçmek için önceki bir değişiklik, süresinde kalan tek sınırı kaldırdı. Platform'un 15 dakikalık infaz sınırı sonra otomatik öldürme-ve-redeliver döngülerini tetikledi ve kilit içeriği beş kez tekrarladı ve 75 dakikalık bir dışlama penceresinden geçti. # **Hazırları ve Davaları Keşfedin Gelen arşiv işleminin çok sayıda etkilenen kullanıcı sıralarını kilitlediğini, diğer tabloyu engellemediğini gördük. Bu, giriş sürecinin etkilenen masadan bağımlılığını ortadan kaldırarak kısa vadede azaltıldı ve sonra arşiv işini düzelterek uzun vadede sabitlendi. Ayrıca, koordinasyonsuz işçinin kilit içeriklenmelerini tespit ettik. Bu, işçi koncurrency'i manuel olarak azaltarak kısa vadede azaltıldı. Bu işleri dengelemek ve serileştirmek için uzun vadeli bir düzeltme planlanmaktadır. Son olarak, giriş ek regresyonun, önceki başarısız girişimlerle kullanıcılar için tüm-bölge giriş başarısızlıklarına neden olduğunu bulduk çünkü sadece bir veritabanı tarafından reddedildi. Bu, tüm bölgelerde dağıtılan ve doğrulanmış bir kod değişikliği ile sabitlendi. # **Proventive Measures** Onlara bağlı olarak büyük grup arşiv operasyonlarımızı geliştiriyoruz, küçük, kararlı toplu işliyor ve veritabanı işlemi dışında dış çağrıları tutuyoruz. Ayrıca, herhangi bir şeyi değiştirmediğini yazmak için belirli bir arka plan çalışanına bir değişiklik kontrol ekledik. Son olarak, veritabanı işlem yaşı için doğrudan uyarılar ekliyoruz ve gecikmeler ek olarak periyodik dolaylı kontrollere ek olarak. # **Müşteri Etkisi ve Kurtarma** Giriş başarısızlıkları ABD bölgesinde yaklaşık 75 dakika sürdü. İki kısa, ABD'nin sadece geri dönüşleri ertesi sabah gerçekleşti ve birkaç dakika içinde manuel olarak temizlendi. Kullanıcı yönetimi gibi bazı yönetim eylemleri de etkilendi. Partner girişleri etkilenmedi. İkinci regresyon yaklaşık 10 saat sürdü ve daha önce bir giriş denemesi başarısız olan kullanıcılar için tüm bölgeleri etkiledi. 18 Eylül öğleden sonra, tüm bölgelerde tam iyileşme doğrulandı ve durum sayfası çözüldü. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi. # **Conclusion** Tek sınırsız bir arka plan işlemi, otomatik bir yeniden deneme mekanizmasıyla birlikte, ABD bölgesinde bir giriş kesintisine neden oldu. Özel tetikleme işi ve yeniden deneme davranışı düzeltildi ve artık rakip yazma yoluna bağlı değildir. Aynı bir regresyon ve iki küçük recurrences her biri saatlerce çözüldü. İşçi koordinasyonu ve veritabanı işlem izlemesi dahil olmak üzere önleyici çalışmalar yukarıda takip edilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
İngiltere örneğimizdeki hesaplar için giriş ve erişim sorunlarına neden olan bir sorunu tespit ettik.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Septermber 8th'de, HTML e-postalarının Classic Outlook'ta rutin bir HTML kütüphanesi yükseltmesi nedeniyle kısmen veya boş olduğunu fark ettik. Web'deki yeni Outlook ve Outlook etkilenmedi. Bu kesinlikle bir ekran meselesiydi: e-posta gecikmedi, kaybedildi veya uzlaşmadı ve tehdit tespit tamamen aktif kaldı. Mühendislik normal işleme geri yüklemek için güncellemeyi yeniden başlattı. Bu pencere sırasında geçici olarak zararlı kod kaldırmanız durumunda, tam koruma sağlamak için yeniden kullanılabilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
E-posta doğrulama MFA'nın İş Alanı için teslim edilmesiyle ilgili bir konu hakkında raporlar aldık. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
E-posta doğrulama MFA'nın İş Alanı için teslim edilmesi ile ilgili konunun Microsoft tarafından azaltıldığını ve sonuçları takip ettiğini bildiriyoruz.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Kullanıcıların işlendiği mesajlarda gecikmeler yaşayabileceği bir sorunu tespit ettik ve mühendislik ekibimiz bir düzeltmeye bakıyor.
Mühendislik ekibimiz PhishER'deki mesaj işleme gecikmelerine neden olan konu için bir düzeltme uyguluyor ve sonuçları takip ediyoruz.
Mühendislik ekibimiz PhishER'de mesaj işleme gecikmelerine neden olan konu için bir düzeltme uyguladı.
# **Summary** 26 Ağustos'ta rutin bir dağıtım sırasında, bir altyapı yönetimi çerçevesi beklenmedik bir şekilde hem birincil mesaj işleme kuyrukları hem de işlenemez mesajları tutan ikincil kuyruklar kaldırıldı. Bu, PhishER müşterilerinin gelen e-posta teslimatını geçici bir kesintiye neden oldu. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi. # **Root Cause** 24 Ağustos 2026'da, içsel bir yapılandırma değişikliği kodumuzla senkronize kayıtları bıraktı. Daha sonra bir kod güncellemesi bu kayıtları iptal etmedi. Bir rutin üretim dağıtım 26 Ağustos 2026'da koştuğunda, aktif yapılandırma kodu taşınmamış kaynak kayıtları içermedi. Sonuç olarak, dağıtım, yönetilmeyen kaynaklar olarak aktif kuyrukları tedavi etti ve onları kaldırdı. # **Mession and Remediation** Otomatik izleme bizi mesaj işlemede bir düşüşe uyarladı ve bir olay yanıt ekibi toplandı. kuyrukların silindiğini bulduk. Bu, eksik kuyrukları yeniden oluşturmak için etkilenen üretim işlerini yeniden çalıştırarak kısa vadede azaltıldı. Daha sonra gerçek zamanlı e-posta işlemenin yeniden başladığını doğruladık. Son olarak, müşterilere gelen kutulara yapılan bulut depolamalarında tutulan e-posta yüklerini yeniden oynattık. # **Timeline** Her zaman UTC'de. * ** 24 Ağustos 2026, 18:41:** İç yapılandırma değişikliği, canlı üretim konfigürasyonuna güncellenmiş kaynak kayıtları yazdı. * ** 26 Ağustos 2026, 15:15:** Bir üretim dağıtım, bağlı kuyrukları ve üretimde işlem edilemeyen mesajları kaldıran kuyrukları ortadan kaldırdı, müşterilere e-posta teslimatını durdurdu. * ** 26 Ağustos 2026, 15:59:** Otomatik izlememiz, mühendislik ekibinin işlendiği sıfır mesajlara uyarıldı ve bir olay yanıt ekibi sayfalandı. * ** 26 Ağustos 2026, 16:01:** kuyrukların silindiğini ve gelen e-posta ödeme yüklerinin hala güvenli bir şekilde depolandığını doğruladık. * ** 26 Ağustos 2026, 16:15:** Birincil kök nedeni olarak yapılandırma yanlışlığını tespit ettik. * ** 26 Ağustos 2026, 16:25:** Takımımız etkilenen üretim işlerini yeniden bekliyor ve kuyruklar yeniden yaratıldı. * ** 26 Ağustos 1826, 18:44:** Otomatik replay, tüm geri çekilen e-postaları müşterilere teslim etmeyi bitirdi. # **Proventative Measures** Gelecekte bu tür bir sorunu önlemek için, üretim öncesi kontrollerden canlı yapılandırılmış bir adım attık ve üretim değişikliklerinden ayrı dağıtım planlamasını kaldırdık. Ayrıca sürümler tamamlandıktan sonra kuyruk sağlığını doğrulamak için otomatik kontroller ekledik. # **Müşteri Etkisi** 15:15'ten 16:25 \(UTC\) 26 Ağustos 2026'da, PhishER'e gönderilen gelen e-postalar müşteri kutularına işlenmedi. Geç e-posta ücretleri, kesintiler boyunca bulut depolamalarında güvenle depolandı. kuyruklar restore edildikten sonra, müşterilere gönderilen otomatik bir replay teslim edildi. Tüm geri kalan mesajlar 18:44 \(UTC\) tarafından teslim edildi. Hiçbir müşteri e-posta verileri bu sorunun bir sonucu olarak kaybedilmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Gmail Phish Alert Düğmesi'nin hatanın "[reportPhishAttempt()] olduğunu bildiriyoruz. İç bir hata oluştu. Lütfen tekrar deneyin." raporlama phish. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Sorun tespit edildi ve bir düzeltme uygulanır.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Cuma günü, 21 Ağustos 2026, yaklaşık 05:20 ila 12:55 \(UTC\), bazı müşteriler Gmail Phish Alert Düğmesini kullanarak, şüpheli e-postaları rapor etmek için, başarılı bir rapor onayı yerine "Bir iç hata meydana geldi" mesajı almak için geçici olarak başarısız oldu. Sorun tüm bölgelerdeki müşterileri etkiledi, en yüksek hata hacimleri AB-West ve ABD-Doğu hizmet bölgelerinde yoğunlaştı. Bu sorun, Google’ın Apps script platformu üzerinde bir kesintiye neden oldu ve ek-kullanıcı oturum yapılandırmasına dayanıyordu. Servis, hala yeni yazı kabul ederken okunan boş sonuçları geri almaya başladı, etkilenen rapor teklifleri başarısız oldu. Be4 Google'ı doğrudan meşgul ve yaklaşık 12:19 ve 12:39 \(UTC\) arasında resmi bir bug raporu açtı. Hata hacmi satıcının durumu temizlendikten kısa bir süre sonra keskin bir şekilde azaldı ve Gmail Phish Alert Düğmesi Düğmesi yaklaşık 12:55 \(UTC\) tarafından normal performansa döndü. Gelecekte bu tür bir sorunu önlemek için, alt katlı kalibrasyon kusurunun çözümünü takip etmek için Google ile çalışmaya devam ediyoruz. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Phish Alert Düğmesi ve "Send Us a Copy" aracılığıyla yayınlanan bir mesaj iade edilmesi için A-Delivery Report (NDR) için bir sorun araştırıyoruz
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Salı günü, 18 Ağustos 2026, yaklaşık 14:10'dan 14:55 \(UTC\) müşteriler Phish Alert Düğmesini kullanarak, **Send Us a Copy** özelliği, **Send Us a Copy** posta kutusu için ücretsiz olarak raporlar aldı. Bu konu, paylaşılan e-posta yönlendirme altyapısına bir yapılandırma değişikliğine neden oldu. Bu değişiklik, hem stilize ve üretim ortamlarımız tarafından kullanılan bir mesajlaşma bileşeni olarak değiştirildi. Çünkü bir üretim kuralı bu paylaşılan bileşene bağlı olarak, yeniden adlandırma başarısızlıklarına neden oldu **Send Us a Copy** posta kutusu ve non-delivery raporlarını tetikledi. Bu sorunu çözmek için, ekibimiz doğru bileşeni referans etmek için etkilenen yapılandırmayı güncelledi ve **Send Us a Copy** özelliği 14:55 \ (UTC\) tarafından normal performansa döndü. Gelecekte bu tür bir sorunu önlemek için, stilize ve üretim ortamlarımız için e-posta yönlendirme konfigürasyonlarını ayırıyoruz. Ayrıca mevcut altyapı yönetim standartlarımıza ait miras konfigürasyonları da yeniden yapılandırıyoruz. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.
Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.
Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.
SAT konsolunda yüklemeden bir hesap ayarını tespit ettik.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay çözüldü.
Salı günü, 4 Ağustos 2026, yaklaşık 18:22 ila 19:43 \(UTC\) bazı müşteriler, CA, DE, EU, İngiltere ve ABD bölgelerindeki KnowBe4 konsolunda yer alan ** platformlarını yüklemiştir. Bu konu, Hesap Ayarları deneyimi tarafından kullanılan bir GraphQL talebinin karmaşıklığını artıran bir dizi uygulama değişikliğine neden oldu. Her değişiklik platformun yapılandırılmış karmaşıklığı eşini bireysel olarak değerlendirdiğinde kaldı, ancak birlikte, istek bu eşiği aştı ve yüklemeden sayfayı engelledi. Mühendislik, katkıda bulunan faktör olarak karmaşıklığı tespit etti ve yaklaşık 19:14 \ (UTC) olarak doğru bir değişim başlattı. Fix etkilenen bölgelerde doğrulandıktan sonra, KnowBe4 konsolu yaklaşık 19:43 \ (UTC\) tarafından normal performansa geri döndü. Bu sorunu gelecekte önlemek için, karmaşık eşi artırdık. Hiçbir veri kaybı bu sorunun bir sonucu olarak gerçekleşmedi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
PhishRIP tarafından beklenmeyen e-postalarla ilgili bir sorunu araştırıyoruz
Bu konu için bir düzeltme uygulanmış ve PhishRIP sorguları artık beklenmedik mesajlara sahip değildir. Hala etkilenebilecek sorguları araştırıyoruz
Bu olay çözüldü.
# **Summary** 28 Temmuz 2026'da, PhishRIP hizmetine bir güncelleme, bazı PhishRIP arama sorgularının sahip olması gerektiğinden daha geniş bir şekilde eşleşmesine neden oldu. Yapılı gönderim kriterleriyle tanışmamış olan Benign e-postalar, bazı müşteri hesaplarında karantinaya alındı. Otomatik izleme ve müşteri destek biletleri sorunu hızla kaldırdı. Mühendislik olayı ilan etmek için yaklaşık 25 dakika içinde değişikliği tekrarladı ve istenmeyen karantinayı bıraktı. Mühendislik daha sonra, müşterilerin gelen kutulara yanlış telaffuz e-postaları manuel olarak restore etti. # **Root'un nedeni 28 Temmuz 2026'da, PhishRIP'in arkasındaki sorgu hizmetine bir bakım güncellemesi kurduk. Bu güncelleme, sistemin sadece adresin domain bölümünü aramasına izin vererek geçersiz posta adreslerini geliştirmek için tasarlanmıştır. Bununla birlikte, mevcut doğrulama mantığı, gönderileyici alanda "@" sembolü gerektiren düzenli bir ifade kullandı. Bir sorgu, [örnek.com) gibi açık bir alan kullandığında (http://ör.com) hiçbir kullanıcı veya "@" sembolü ile, regex domaini geçersiz kılmıştır. Mevcut geçerlilik ve alan arama güncellemesi arasındaki bu çatışma, sistemin tamamen gönderileyici kriterleri düşmesine neden oldu. Soru, yalnızca kalan parametrelerini, eşleşen ve amaçlanan gönderileyici dışındaki e-postaları kullanarak gelen kutulara karşı koştu. # **Timeline** Her zaman UTC'de. | **Time** | ** Event** | | --- | | 19:36 | Otomatik izlememiz anormal sorgu yürütme modellerini tespit etti ve hemen araştırmaya başlayan mühendislerimizi uyardı. | | 19:51 | Sorun yüksek sualtı üretim olayına yükseldi ve bir yanıt ekibi toplandı. | | 19:52 | Destek ekibimiz beklenmedik kurantines bildirilen ilk müşteri biletlerini artırdı, izleme uyarısını teşvik etti. | | 19:54 | Kök nedeni son bir sorgu API dağıtımına izlendi ve mühendislik değişikliği tekrarlamaya başladı. | | 20:00 | Olay iletişim durumu sayfamıza gönderildi, PhishRIP Degraded olarak işaretlendi. | | 20:16 | Dağıtım tamamen geri alındı. | | 20:35 | Üretim kontrolleri, konu ve alan sorgularının sadece amaçlanan hedeflerini eşleştirildiğini doğruladı ve daha fazla mesaj yanlış anlaşılmadı. Durum sayfamız buna göre güncellendi. | | 20:39 | Mühendislik yanlış telaffuz edilen e-postaları restore etmeye başladı. | | 03:49 \( next day\) | Restorasyonlar, destek ekibimiz aracılığıyla giriş yapan tüm müşteri sorgu setleri için tamamlandı. | # **Mitigation and remediation** **Kore geri döndü.** Kodu yeniden başlatmaya karşı aktif PhishRIP operasyonlarının durdurulmasına karar verdik. Arka görevlerin her onant için meşru güvenlik iş akışlarını kesintiye uğratılması, bu yüzden tekrarlama daha iyi bir seçenekti. Kod iptal edildi ve yaklaşık 40 dakika içinde üretimde doğrulandı. **Email restorasyonu. ** Gerçekten kötü niyetli e-postaları müşteri ortamlarına geri bırakmaktan kaçınmak için, onları toplu olarak yerine manuel olarak restore ettik. Mühendislik, her hesabı ID, sorgu ID'yi doğrulamak için e-postaları geri yüklemek ve önce müşteri onayını almak için iç yönetim araçları kullandı. Tüm bildirilen hesaplar bir gecede restore edildi. # **Proventatif önlemler** * **Regresyon kapsamı**: Alan için ünite ve entegrasyon testleri ekliyoruz, standart olmayan ve dağıtımdan önce bu giriş davalarını yakalamak için çıplak çağrılı sorgular. * **Query guardrails**: Temel filtreleme parametrelerinin değerlendirme sırasında düştüğünüzden sorgulanan sorgu motorunda bir kontrol ekliyoruz. # **Conclusion** Tek bir doğrulama kuralı buna neden oldu: her gönderici alanın bir “@” olduğunu varsayan bir regex. Sorular açık bir alan kullandığında, bu varsayım gönderileyici filtreyi bıraktı ve sorgular amaçlanandan çok daha fazla postayla eşleştirildi. Fix bir kez onu bulduğumuzda basitti ve Revert olayı ilan etmek için yaklaşık 25 dakika içinde zararı durdurdu. Restoring quarantined posta daha zor bir süreçtir: Gerçekten kötü niyetli e-postaların inboxes'e geri dönmesi riski olmadan toplu olarak e-postaları geri getiremedik. Ekibimiz, gece boyunca destekle hesaplayarak dikkatle devam etmeyi seçti. İki önleyici önlemler bunu daha önce yakalayacaktı: sadece domain-sadece gönderen sorgular ve gönderen bir bekçi filtre kaldırıldı. Her ikisi de şimdilik planlanmaktadır. Hemen sorun çözüldü ve tüm bildirilen hesaplar restore edildi. # **Glossary** * **PhishRIP:** Yöneticilerin bir organizasyondaki her kullanıcıdan gelen e-postaları aramasını sağlayan bir PhishER özelliği. * **Regex \(regular ekspresi) =** Bir e-posta adresinin doğru şekilde formatlandığını kontrol etmek için yazılımda kullanılan bir desen. * **Kore geri döndü:** Önceki stabil sürüme dönmek için bir yazılım güncellemesini geri yükleyin.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Kullanıcıların mağazadaki lisansları satın alamadığını araştırıyoruz.knowbe4.com. Bu sayfayı daha fazla bilgimiz olduğunda güncelleyeceğiz.
Bir düzeltme uyguluyoruz ve sonuçları daha fazla sorun yaşanmadığından takip ediyoruz.
Müşterilerimizin mağazadaki lisansları satın alamadığı raporlar aldık.knowbe4.com. Bu konuyu araştırıyoruz ve daha fazla bilgimiz olduğunda bu sayfayı güncelleyeceğiz.
Online mağaza için bir düzeltme yaptık ve sonuçları daha fazla sorun yaşamadığından izlemeliyiz.
Online mağaza için uygulanan düzeltmeyi izlemeye devam ediyoruz, daha fazla sorun yaşanmamasını sağlamak için.
Bu olay çözüldü.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
