500 ימי האפס של Claude Opus 4.6: מה שלושה תיקונים מראים

ב-5 בפברואר 2026 פרסם צוות Frontier Red Team של Anthropic מחקר המדווח כי Claude Opus 4.6, שיצא באותו יום, מצא ואימת יותר מ-500 פגיעויות בעלות חומרה גבוהה בתוכנה בקוד פתוח — ללא כלים ייעודיים למשימה, תשתית מותאמת אישית או הנחיה מיוחדת. שלושה ממצאים מתוארים בפירוט: בדיקת גבולות מחסנית חסרה ב-Ghostscript, סדרה לא בדוקה של קריאות strcat ב-OpenSC, וגלישת מאגר במקודד ה-GIF בשם CGIF שתלויה באופן שבו דחיסת LZW מתנהגת כשהמילון שלה מתמלא. Anthropic אומרת שכל השלושה תוקנו כעת על ידי המתחזקים שלהם, ולפי התיאור שלה הבאגים נמצאו, אומתו ודווחו. רבים מהפרויקטים מתוחזקים על ידי צוותים קטנים או מתנדבים ללא צוות אבטחה ייעודי, נכתב בפוסט, ולכן עומס הדיווח והתיקון נפל עליהם. הרשומה של הארכיון עצמו עבור הממצא, בדירוג חומרה info וללא נזק ממשי שנרשם, נמצאת בOrca AI Incident Archive לצד רשומות המדיניות והגילוי האחרות מפברואר 2026.

מה ש-Anthropic פרסמה בפועל

הפוסט נקרא "הערכה והפחתה של הסיכון הגובר של 0-days שמתגלים על ידי LLM" ומיוחס ל-Frontier Red Team: ניקולס קרליני, קין לוקאס ואביתר בן אשר כתורמים שווים, עם ניוטון צ'נג, חסנין לאקהאני, דייוויד פורסיית' וקיילה גורו. בעמוד מופיע תאריך פרסום של 5 בפברואר 2026 והערת עריכה מתאריך 6 בפברואר 2026 המתעדת שרשימת המחברים עודכנה. הארכיון מציין את הפוסט בכתובת red.anthropic.com, אשר מפנה כעת אל anthropic.com/research/zero-days.

השיטה חשובה יותר ממספר הכותרת. Anthropic אומרת שהציבה את המודל בתוך מכונה וירטואלית עם גישה לגרסאות העדכניות של פרויקטי קוד פתוח, וסיפקה לו כלי עזר סטנדרטיים ואת הכלים שבהם חוקר אבטחה אנושי היה משתמש — דיבאגרים ופאזרים — אך ללא הוראות כיצד להשתמש בהם, ובלשון הפוסט, "ללא רתמה מותאמת אישית שהייתה מעניקה לו ידע מיוחד כיצד לאתר פגיעויות טוב יותר". מה שנבחן היה התנהגות המודל כפי שהיא מהקופסה.

הצוות צמצם את החיפוש לבאגים של השחתת זיכרון, בנימוק שקריסה קלה יותר לאימות משגיאת לוגיקה. Anthropic מבהירה במפורש שזהו מסנן, לא ערובה: "לא כל הקלטים שגורמים לתוכנית לקרוס הם פגיעויות בדרגת חומרה גבוהה." אז הקריסות חזרו למודל כדי לבקר, להסיר כפילויות ולתעדף מחדש, ואז לאנשים. "בסבב הממצאים הראשוני שלנו, חוקרי האבטחה שלנו אימתו כל פגיעות וכתבו תיקונים ביד. ככל שנפח הממצאים גדל, הבאנו חוקרי אבטחה חיצוניים (אנושיים) כדי לסייע באימות ובפיתוח תיקונים." אוטומציה של תיקונים, נאמר בפוסט, עדיין הייתה בבנייה.

שלושה באגים, והתיקונים שבאו בעקבותיהם

שלוש הדוגמאות המופתרות חולקות דפוס משותף: כלי אוטומטי כבר נכשל, והמודל מצא את הבאג באמצעות הסקה על משהו אחר מאשר מוטציית קלט.

• Ghostscript, מפרש ה-PostScript וה-PDF. פיזינג ולאחר מכן ניתוח ידני לא העלו דבר. לאחר מכן המודל קרא את היסטוריית ה-Git של הפרויקט, מצא קומיט שתואר בפוסט כמוסיף "בדיקת גבולות מחסנית עבור ערכי MM blend" ל-charstrings מסוג Type 1, הסיק שהקוד לפני אותו קומיט היה פגיע, ויצא לחפש אתרי קריאה אחרים שלא קיבלו את אותו טיפול. הוא מצא אחד ב-gdevpsfx.c — הפוסט מציין שורה 292 — ובנה קובץ שמקריס את התוכנית. המאגר מאשש זאת: קומיט 87486fb801 מאת Chris Liddell, מתאריך 5 בספטמבר 2025, שכותרתו "Type 1 charstrings: add stack bounds checking for MM blend values." תיקון מאוחר יותר מאת Ken Sharp, קומיט 4e392a82 מתאריך 26 בינואר 2026, מוסיף בדיקות גבולות מיד לפני אותה קריאה בממיר הגופנים, שהוגש נגד באג 709080, שדוחו נקרא "Ghostscript Incomplete fix for Type 1 MM blend stack bounds check". קומיט מ-13 בפברואר 2026 הרחיב בדיקות גבולות באותו ממיר. אף אחת מהודעות הקומיט לא אומרת מי דיווח על הבאג.

• OpenSC, כלי שורת פקודה לנתוני כרטיסים חכמים. כאן המודל חיפש קריאות פונקציה מסוכנות ומצא פעולות strcat עוקבות שכתבו אל חיץ filename בגודל 4096 בתים, לאחר חישוב גודל שהחסיר את אורך מחרוזת קלט אך הוסיף מחרוזות נוספות ללא בדיקה חוזרת. הפוסט מציין שהפאזרים הקיימים הגיעו לעיתים רחוקות לנתיב הזה בגלל התנאים המוקדמים המעורבים. הקומיט 33ab343a5c של OpenSC מ-19 בינואר 2026 הוסיף בדיקה שהמחרוזת המצורפת היא באורך בדיוק 64 בתים, ובקשת המשיכה #3554, שמוזגה ב-25 בינואר 2026, החליפה את קריאות ה-strcat הנותרות ברחבי הפרויקט ב-strlcat; המחבר שלה כינה את הפונקציה "מגנט לכל כלי ניתוח סטטי ול-CVE-ים."

• CGIF, מקודד GIF. הספרייה הניחה שנתונים דחוסים תמיד יהיו קטנים יותר מהקלט הלא דחוס, מה שכמעט תמיד נכון. המודל הסיק ש-LZW בונה מילון בגודל קבוע, ושכאשר המילון מתמלא, קודי ניקוי המוכנסים לזרם יכולים לגרום לפלט ה"דחוס" להיות ארוך יותר מהקלט — כך שמאגר בגודל N+2 קודים יכול לקבל יותר מ-N+1. הפוסט אומר שאפילו כיסוי שורות וענפים של 100 אחוז עשוי לא לחשוף זאת, כי זה דורש רצף פעולות מסוים. בקשת המשיכה #84 של CGIF, שמוזגה ב-19 בינואר 2026 ושוחררה באותו יום כ-v0.5.1, מתקנת בדיוק את זה: "קודי הניקוי לאיפוס היו חסרים בחישוב של החסם העליון לגודל נתוני LZW."

התיקונים הללו נכנסו לפני פרסום המחקר — CGIF ו-OpenSC ב-19 בינואר 2026, OpenSC שוב ב-25 בינואר, Ghostscript ב-26 בינואר — ואנתרופיק אמרה בפוסט שהיא "החלה לדווח עליהם ורואה את הטלאים הראשוניים שלנו נכנסים" לפני שיצאה לציבור. המאגרים מתעדים את שינויי הקוד; הם אינם מתעדים מי הגיש את הדיווחים, ולכן הקשר בין ממצאי המודל לבין הקומיטים המסוימים הללו נשען על דבריה של אנתרופיק ועל מידת ההתאמה בין הפגמים המתוארים לבין ה-diffs.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

חצי הממשל: בדיקות, חסימה ו-90 ימים

מה שהופך את זה לרשומת מדיניות ולא להערת מחקר רגילה הוא המחצית השנייה של הפוסט. לצד שחרור המודל, Anthropic אומרת שהציגה פרובים ייעודיים לסייבר שמודדים אקטיבציות בתוך המודל בזמן שהוא מייצר תגובה, ושעדכנה את זרימות האכיפה שלה כך שישתמשו בזיהוי מבוסס פרובים. זה מרחיק לכת מעבר לזיהוי: "ייתכן שנפעיל התערבות בזמן אמת, כולל חסימת תעבורה שאנו מזהים כזדונית." Anthropic מודה במחיר — "זה ייצור חיכוך למחקר לגיטימי ולחלק מעבודת ההגנה" — ואומרת שהיא רוצה לעבוד עם קהילת מחקר האבטחה בנושא. לא מפורסמים שיעור זיהוי, שיעור שגיאות או תהליך ערעור.

הפוסט גם טוען שלוח הזמנים של החשיפה עצמו הוא כעת בעיה. "חלונות של 90 יום, התקן בתעשייה, עשויים שלא להחזיק מעמד מול המהירות והנפח של באגים שמתגלים על ידי מודלי שפה גדולים," נאמר בו, והוא מזהיר שהמודלים "עשויים בקרוב לעלות על המהירות והקנה מידה של אפילו חוקרים אנושיים מומחים." זהו ספק שטוען שהנורמה שלפיה יישפט צריכה להיות מוחלפת, וזה החלק בתיעוד בעל ההשפעה הרחבה ביותר.

מה השתנה לאחר מכן

ב-20 בפברואר 2026 אנתרופיק השיקה את Claude Code Security בתצוגה מקדימה מחקרית מוגבלת ללקוחות Enterprise ו-Team, עם גישה מואצת בחינם למתחזקי קוד פתוח — היכולת הפכה למוצר חמישה עשר יום לאחר המחקר. VentureBeat דיווחה על ההשקה ואמרה כי ביקשה מאנתרופיק את שיעור החיוביים-המדומים לפני ואחרי אימות עצמי, את מספר הפגיעויות שנחשפו שתיקונים עבורן נכנסו לעומת אלו שעדיין במיון, ואת אמצעי ההגנה המבחינים בין שימוש של תוקף לשימוש של מגן; היא דיווחה כי החוקר הראשי בפרויקט לא היה זמין וכי החברה סירבה לחלוק מנגנוני זיהוי תוקפים ספציפיים.

גם התיקונים המשיכו לזוז, ולא תמיד בכיוון אחד. התיקון של CGIF לבעיית ההקצאה שתיארה Anthropic יצא ב-v0.5.1 ב-19 בינואר 2026; ב-21 בפברואר 2026, בקשת המשיכה #103 תיקנה גלישת מספר שלם של 32 סיביות שנוצרה מאותו חישוב הקצאה, ושוחררה כ-v0.5.2 למחרת עבור קובצי GIF בגודל המרבי של 65,535 על 65,535 פיקסלים. מתברר שתיקון חישוב גבולות הוא בעצמו מקור קטן לבאגים של גבולות.

לקרוא את המספר נכון

המשפט של Anthropic עצמה הוא "יותר מ-500 פגיעויות בחומרה גבוהה". Axios, שאליו החברה מסרה תדרוך ראשון, תיאר אותן ביום הפרסום כ"יותר מ-500 פגיעויות zero-day שלא היו ידועות קודם לכן", שכל אחת מהן אומתה על ידי חבר בצוות של Anthropic או חוקר אבטחה חיצוני. שני התיאורים מצביעים על אותה קבוצה, אך רק אחד הוא הניסוח של הספק, ואף אחד מהם אינו מלווה ברשימה, במיפוי CVE או בפיזור חומרה. הספירה היא של Anthropic, דירוגי החומרה הם של Anthropic, ושלושת הפרויקטים שנסקרו בפוסט הם היחידים שהציבור יכול לבדוק.

הניתוח העצמאי שבא לאחר מכן קיבל את המספר ברובו כפשוטו והתווכח על משמעותו. מיץ' אשלי מ-Futurum Group כתב ב-24 בפברואר 2026 שהתוצאה "חשובה יותר בגלל מה שהשיטה חושפת מאשר בגלל הספירה", ושהמגבלה האמיתית נמצאת במורד הזרם: "חשיפה מהירה יותר של יותר פגיעויות אינה מקטינה את משטח התקיפה. היא בונה תור גדול יותר לפני תהליך במורד הזרם שאינו יכול לקלוט את הנפח." זו ביקורת על צינור החשיפה ולא על הממצא, והיא נוגעת באותה נקודה שהעלתה Anthropic בנוגע לחלונות של 90 יום.

מה שהתיעוד אינו מבסס

הארכיון מדרג את הרשומה הזו ברמת מהימנות A, חומרה info, כשלא תועד נזק ממשי ולא סומנה מחלוקת. הדירוג הזה עוסק במידת התיעוד של האירוע, לא במידת הביקורת שנעשתה על הטענה הבסיסית, וכדאי לשמור על ההבחנה הזו. איש מחוץ ל-Anthropic לא אימת את 500 המקרים. שיעור חיוביים שגויים לא פורסם. הטלאים לשלושת הפרויקטים הנקובים בשמם אמיתיים וניתנים לתיארוך, והם החיזוק החזק ביותר הזמין — אבל הם מחזקים שלוש דוגמאות, לא את המכלול.

מה שנותר, אם כן, הוא הכרזה מתועדת היטב עם ליבה ניתנת לבדיקה ושארית שאינה ניתנת לבדיקה: ספק המדווח על יכולת, שלושה דיפים במעלה הזרם התואמים את תיאור הבאגים שלו, וכוונה מוצהרת לפקח על שימוש לרעה ביכולת זו בשכבת המודל. הארכיון מתייק אותה כמדיניות, וזה המדף הנכון. טענת היכולת תוכרע בידי מי שיפרסם את הטלאי הרביעי.