Oracle publică patch-uri lunar, nu trimestrial: 673 de corecții în septembrie și un calendar de revizuit

Mulți ani, procesul de patching Oracle dintr-o organizație se putea rezuma la patru date pe an. Nu mai este cazul. Oracle rulează acum două programe în paralel, iar propria pagină de securitate o spune explicit: „Patch-urile de securitate sunt lansate în a treia zi de marți a fiecărei luni.”

Critical Patch Update rămâne ediția trimestrială cumulativă. Peste ea, Oracle a adăugat Critical Security Patch Update, descris de companie drept „corecții de securitate țintite, de prioritate ridicată, într-un format mai mic și mai concentrat, mai ușor de aplicat cu perturbare minimă” și prezentat ca fiind complementar ciclului trimestrial.

Concret, următoarele patru date anunțate de Oracle sunt: 20 octombrie 2026 (CPU), 17 noiembrie 2026 (CSPU), 15 decembrie 2026 (CSPU) și 19 ianuarie 2027 (CPU). Dacă în calendarul intern al echipei tale apar doar ianuarie, aprilie, iulie și octombrie, ratezi două treimi din ediții.

• Confirmat de Oracle: ediția din septembrie 2026 conține 673 de corecții de securitate noi, iar patch-urile se lansează acum în a treia zi de marți a fiecărei luni, alternând CPU și CSPU.
• Confirmat de Oracle: recomandarea companiei este ca beneficiarii „să rămână pe versiuni cu suport activ și să aplice patch-urile de securitate fără întârziere”.
• Confirmat de INCIBE-CERT: repartiția pe severități — 104 critice, 503 ridicate, 58 medii, 7 scăzute — și lista extinsă de produse afectate.
• Confirmat de CERT-Bund: o avertizare separată, de severitate înaltă, pentru vulnerabilitățile din Oracle Supply Chain.
• Necunoscut public: care dintre aceste vulnerabilități sunt exploatate activ în acest moment. Oracle nu publică o listă de exploatare per ediție, iar prezența în catalogul KEV al CISA apare, de regulă, mai târziu și doar pentru o parte dintre ele.
• Necunoscut: câte organizații din România rulează produsele afectate și în ce versiuni. Acesta este exact răspunsul pe care trebuie să îl aibă inventarul tău, nu un articol.

Advisory-ul conține o frază care spune mai mult despre cum se pierd organizațiile decât orice statistică: Oracle relatează că primește periodic raportări despre încercări de exploatare a unor vulnerabilități pentru care corecțiile existau deja și adaugă că „în unele cazuri, s-a raportat că atacatorii au avut succes pentru că beneficiarii vizați nu aplicaseră patch-urile Oracle disponibile”.

Cu alte cuvinte, problema documentată de furnizor nu este lipsa corecției, ci distanța dintre publicarea ei și aplicarea efectivă. Pentru un sistem ERP sau o bază de date care susține facturarea, producția sau raportarea financiară, distanța aceea se măsoară adesea în luni, pentru că fereastra de mentenanță cere aprobări, testare și oprirea unui serviciu de care depinde toată organizația.

Tot Oracle avertizează și asupra soluțiilor temporare: blocarea protocoalelor sau retragerea unor privilegii „pot afecta funcționalitatea aplicației”, trebuie testate pe sisteme care nu sunt de producție și nu reprezintă o soluție de durată, „pentru că niciuna nu corectează problema de fond”.

• Actualizează calendarul de patching cu ambele cicluri. Cele patru date publicate de Oracle intră în calendarul echipei, cu un responsabil numit pentru fiecare, nu cu o listă de distribuție.
• Fă inventarul produselor Oracle pe care le rulezi efectiv, cu versiune și status de suport. Lista INCIBE are în jur de 70 de produse; nu ai nevoie să le urmărești pe toate, ci să știi precis care sunt ale tale. Include și instanțele administrate de un integrator sau de un furnizor de servicii gestionate.
• Verifică statusul de suport separat de versiune. Recomandarea Oracle de a rămâne pe versiuni cu suport activ este, în practică, o decizie de buget și de contract, nu una tehnică. O versiune ieșită din suport nu primește corecțiile din aceste ediții, indiferent cât de repede reacționează echipa ta.
• Stabilește dinainte cine aprobă o fereastră de mentenanță de urgență pentru sistemele critice și în ce condiții. Dacă răspunsul se construiește abia când apare o vulnerabilitate exploatată activ, ai pierdut deja primele zile.
• Dacă folosești soluții temporare de tipul blocării unui protocol, notează-le explicit ca excepții cu termen și proprietar. Oracle spune singur că nu sunt soluții de durată; o excepție fără termen devine o configurație permanentă pe care nimeni nu o mai revizuiește.

Un raport util nu spune „am aplicat patch-urile Oracle”. Arată ce produse Oracle există în organizație, în ce versiuni și cu ce status de suport, care ediții au fost evaluate, ce s-a aplicat și când, ce a rămas deschis, cine deține fiecare excepție și până la ce dată. Pentru sistemele care nu pot fi oprite imediat, arată și ce măsuri compensatorii au fost puse între timp.

Pentru o organizație aflată în sfera NIS2, această trasabilitate susține managementul vulnerabilităților și guvernanța furnizorilor, fără a echivala automat cu conformitatea legală, care rămâne evaluarea proprie a organizației. Awarely Monitor poate urmări edițiile, activele afectate, responsabilii și dovada închiderii; decizia asupra ferestrei de mentenanță și a riscului rămâne a echipei.