Threat Signal

😈VLC 3.0.23 - Overflow 2 Remote Code Execution (chain) 👋DEP/NX + ASLR (win11-x64) 💻@ThreatSignal

😈VLC 3.0.23 - 'MMS/MMSh' OOB & Integer Overflow 🏷Proof-of-Concept launcher for two VLC MMS/MMSh memory-safety research cases 🏷modules/access/mms/buffer.c:197 🏷modules/access/mms/mmsh.c:760 🟢PoC : https://github.com/AryanChehreghani/vlc-oob-overflow-poc 💻@ThreatSignal

🏛اگر مشکل ورود به Antigravity دارید AvenCores که تو زمینه Unlock , Patch ,... فعالیت داره یک Patcher براش نوشته که میتونید برای آخرین نسخه ها ازش استفاده کنید ♾https://github.com/AvenCores/open-antigravity-patcher ⬅️اول آخرین نسخه رو دانلود کنید ، یکبار وارد حساب خودتون بشید وقتی با ارور مواجه شد وارد Patcher بشید بعد از Patch دوباره وارد حساب خودتون بشید اینبار بدون خطا و محدودیت وارد Antigravity خواهید شد این پیغام ها مربوط به موقعیت مکانی شماست ( ترفند های زیادی وجود دارن برای عبور از این محدودیت ) 💻@ThreatSignal

پست موقت : بچه‌ها یه خواهش ازتون دارم... ❤️ می‌خوام برای کشورم یه قدم، هرچند کوچیک، توی حوزه امنیت هوش مصنوعی بردارم برام اصلاً مهم نیست اسمم جایی مطرح بشه یا کسی منو بشناسه فقط دوست دارم اگر تونستم یه اثر مثبت از خودم به جا بذارم. فقط از ته دل برام آرزوی موفقیت کنید شاید با کمک خدا بتونیم یه قدم خوب برداریم و سهم کوچیکی توی این حوزه داشته باشیم چون کشورمون واقعا به دلایل مختلفی هیچ سهمی توی اینا نداره 🤍🇮🇷

بنظرتون Emmanuel Guilherme چی گفت ؟ 😎 💻@ThreatSignal

🗣️Why AI Security Needs a Different Threat Model One of my main concerns with the OWASP GenAI Security Project is that it still approaches AI security largely through the lens of traditional application security. This approach is understandable. AI systems are still software systems, and they remain exposed to familiar risks such as insecure access control, data leakage, supply-chain compromise, misconfiguration, and unsafe API integration. However, these risks represent only part of the attack surface.

Traditional software is mostly deterministic. Developers define the program logic, users provide input, and the application executes a relatively predictable sequence of instructions. Security testing therefore focuses on identifying situations where an attacker can bypass a technical boundary, manipulate data, inject executable content, or reach functionality that should not be accessible. AI systems, particularly large language models and autonomous agents, behave differently. Their outputs are probabilistic, context-dependent, and influenced by natural-language instructions. In these systems, language is not only data. It can also function as instruction, context, authority, memory, and behavioral guidance. Because of this, an attacker may not need to exploit memory corruption, inject code, or bypass a conventional authorization mechanism. Instead, the attacker may manipulate the model’s interpretation of the situation. For example, an attacker could: gradually redefine the model’s objective across multiple interactions; introduce false assumptions that influence later decisions; exploit conflicts between system instructions, user requests, and retrieved content; poison long-term memory or external knowledge sources; frame a malicious action as a legitimate exception; manipulate an agent into using an authorized tool for an unauthorized purpose; create a sequence of individually acceptable requests that produces a harmful result when combined. These are not always traditional software vulnerabilities. They are semantic, behavioral, and contextual vulnerabilities. This is why describing AI security only through categories such as prompt injection, insecure output handling, excessive agency, or data poisoning may be insufficient. These categories are useful, but they are broad labels. They do not fully describe how an attacker can influence the internal decision process of an AI system over time. A more complete AI security framework should separate at least the following layers: 1. Infrastructure and application security This includes APIs, authentication, authorization, secrets management, sandboxing, dependencies, and cloud configuration. 2. Data and knowledge security This includes training-data poisoning, retrieval poisoning, embedding manipulation, source integrity, and unauthorized disclosure of sensitive information. 3. Semantic and behavioral security This layer covers instruction conflicts, contextual manipulation, role manipulation, objective redirection, deceptive framing, and multi-turn behavioral exploitation. 4. Memory and identity security AI systems with persistent memory can be exposed to memory poisoning, identity confusion, false user profiling, cross-session contamination, and manipulation of stored preferences or beliefs. 5. Agent and action security Autonomous agents introduce risks related to tool usage, planning, delegation, privilege boundaries, action sequencing, and unintended chains of execution. 6. Human–AI interaction security The system may be technically uncompromised while still causing harm through overconfidence, misleading explanations, emotional influence, automation bias, or false claims of authority. 7. Societal and systemic security At scale, AI systems may enable automated persuasion, coordinated misinformation, synthetic identity attacks, feedback loops between models, and large-scale manipulation of information environments. It is important not to treat an AI model as a human being. A model does not have human emotions, intentions, or psychological needs. However, many attacks against AI resemble social-engineering techniques because language models are sensitive to framing, authority signals, role definitions, narrative structure, and contextual pressure. In other words, the attacker is not exploiting human psychology inside the model. The attacker is exploiting learned behavioral patterns that produce human-like responses. The core issue is therefore not that existing OWASP categories are incorrect. The issue is that application-security terminology alone cannot fully represent the security properties of probabilistic and context-sensitive systems. In traditional software security, the main question is often: Can the attacker bypass a technical control? In AI security, additional questions are necessary: Can the attacker alter the system’s understanding of the task? Can the attacker redirect its objective without directly violating a technical rule? Can the attacker influence its memory, reasoning process, trust model, or use of tools? Can a sequence of harmless-looking interactions produce a harmful system-level outcome? AI security therefore requires more than an expanded version of application security. It requires a multi-layer threat model that covers technical controls, data integrity, semantic manipulation, behavioral influence, memory, autonomous action, human interaction, and broader systemic consequences.

💻@ThreatSignal

Why AI Security Needs a Different Threat Model One of my main concerns with the OWASP GenAI Security Project is that it still approaches AI security largely through the lens of traditional application security. This approach is understandable. AI systems are still software systems, and they remain exposed to familiar risks such as insecure access control, data leakage, supply-chain compromise, misconfiguration, and unsafe API integration. However, these risks represent only part of the attack surface. Traditional software is mostly deterministic. Developers define the program logic, users provide input, and the application executes a relatively predictable sequence of instructions. Security testing therefore focuses on identifying situations where an attacker can bypass a technical boundary, manipulate data, inject executable content, or reach functionality that should not be accessible. AI systems, particularly large language models and autonomous agents, behave differently. Their outputs are probabilistic, context-dependent, and influenced by natural-language instructions. In these systems, language is not only data. It can also function as instruction, context, authority, memory, and behavioral guidance. Because of this, an attacker may not need to exploit memory corruption, inject code, or bypass a conventional authorization mechanism. Instead, the attacker may manipulate the model’s interpretation of the situation. For example, an attacker could: gradually redefine the model’s objective across multiple interactions; introduce false assumptions that influence later decisions; exploit conflicts between system instructions, user requests, and retrieved content; poison long-term memory or external knowledge sources; frame a malicious action as a legitimate exception; manipulate an agent into using an authorized tool for an unauthorized purpose; create a sequence of individually acceptable requests that produces a harmful result when combined. These are not always traditional software vulnerabilities. They are semantic, behavioral, and contextual vulnerabilities. This is why describing AI security only through categories such as prompt injection, insecure output handling, excessive agency, or data poisoning may be insufficient. These categories are useful, but they are broad labels. They do not fully describe how an attacker can influence the internal decision process of an AI system over time. A more complete AI security framework should separate at least the following layers: 1. Infrastructure and application security This includes APIs, authentication, authorization, secrets management, sandboxing, dependencies, and cloud configuration. 2. Data and knowledge security This includes training-data poisoning, retrieval poisoning, embedding manipulation, source integrity, and unauthorized disclosure of sensitive information. 3. Semantic and behavioral security This layer covers instruction conflicts, contextual manipulation, role manipulation, objective redirection, deceptive framing, and multi-turn behavioral exploitation. 4. Memory and identity security AI systems with persistent memory can be exposed to memory poisoning, identity confusion, false user profiling, cross-session contamination, and manipulation of stored preferences or beliefs. 5. Agent and action security Autonomous agents introduce risks related to tool usage, planning, delegation, privilege boundaries, action sequencing, and unintended chains of execution. 6. Human–AI interaction security The system may be technically uncompromised while still causing harm through overconfidence, misleading explanations, emotional influence, automation bias, or false claims of authority. 7. Societal and systemic security At scale, AI systems may enable automated persuasion, coordinated misinformation, synthetic identity attacks, feedback loops between models, and large-scale manipulation of information environments. It is important not to treat an AI model as a human being. A model does not have human emotions, intentions, or psychological needs. However, many attacks against AI resemble social-engineering techniques because language models are sensitive to framing, authority signals, role definitions, narrative structure, and contextual pressure. In other words, the attacker is not exploiting human psychology inside the model. The attacker is exploiting learned behavioral patterns that produce human-like responses. The core issue is therefore not that existing OWASP categories are incorrect. The issue is that application-security terminology alone cannot fully represent the security properties of probabilistic and context-sensitive systems. In traditional software security, the main question is often: Can the attacker bypass a technical control? In AI security, additional questions are necessary: Can the attacker alter the system’s understanding of the task? Can the attacker redirect its objective without directly violating a technical rule? Can the attacker influence its memory, reasoning process, trust model, or use of tools? Can a sequence of harmless-looking interactions produce a harmful system-level outcome? AI security therefore requires more than an expanded version of application security. It requires a multi-layer threat model that covers technical controls, data integrity, semantic manipulation, behavioral influence, memory, autonomous action, human interaction, and broader systemic consequences. 💻@ThreatSignal

Why AI Security Needs a Different Threat Model One of my main concerns with the OWASP GenAI Security Project is that it still approaches AI security largely through the lens of traditional application security. This approach is understandable. AI systems are still software systems, and they remain exposed to familiar risks such as insecure access control, data leakage, supply-chain compromise, misconfiguration, and unsafe API integration. However, these risks represent only part of the attack surface. Traditional software is mostly deterministic. Developers define the program logic, users provide input, and the application executes a relatively predictable sequence of instructions. Security testing therefore focuses on identifying situations where an attacker can bypass a technical boundary, manipulate data, inject executable content, or reach functionality that should not be accessible. AI systems, particularly large language models and autonomous agents, behave differently. Their outputs are probabilistic, context-dependent, and influenced by natural-language instructions. In these systems, language is not only data. It can also function as instruction, context, authority, memory, and behavioral guidance. Because of this, an attacker may not need to exploit memory corruption, inject code, or bypass a conventional authorization mechanism. Instead, the attacker may manipulate the model’s interpretation of the situation. For example, an attacker could: gradually redefine the model’s objective across multiple interactions; introduce false assumptions that influence later decisions; exploit conflicts between system instructions, user requests, and retrieved content; poison long-term memory or external knowledge sources; frame a malicious action as a legitimate exception; manipulate an agent into using an authorized tool for an unauthorized purpose; create a sequence of individually acceptable requests that produces a harmful result when combined. These are not always traditional software vulnerabilities. They are semantic, behavioral, and contextual vulnerabilities. This is why describing AI security only through categories such as prompt injection, insecure output handling, excessive agency, or data poisoning may be insufficient. These categories are useful, but they are broad labels. They do not fully describe how an attacker can influence the internal decision process of an AI system over time. A more complete AI security framework should separate at least the following layers: 1. Infrastructure and application security This includes APIs, authentication, authorization, secrets management, sandboxing, dependencies, and cloud configuration. 2. Data and knowledge security This includes training-data poisoning, retrieval poisoning, embedding manipulation, source integrity, and unauthorized disclosure of sensitive information. 3. Semantic and behavioral security This layer covers instruction conflicts, contextual manipulation, role manipulation, objective redirection, deceptive framing, and multi-turn behavioral exploitation. 4. Memory and identity security AI systems with persistent memory can be exposed to memory poisoning, identity confusion, false user profiling, cross-session contamination, and manipulation of stored preferences or beliefs. 5. Agent and action security Autonomous agents introduce risks related to tool usage, planning, delegation, privilege boundaries, action sequencing, and unintended chains of execution. 6. Human–AI interaction security The system may be technically uncompromised while still causing harm through overconfidence, misleading explanations, emotional influence, automation bias, or false claims of authority. 7. Societal and systemic security At scale, AI systems may enable automated persuasion, coordinated misinformation, synthetic identity attacks, feedback loops between models, and large-scale manipulation of information environments. It is important not to treat an AI model as a human being. A model does not have human emotions, intentions, or psychological needs. However, many attacks against AI resemble social-engineering techniques because language models are sensitive to framing, authority signals, role definitions, narrative structure, and contextual pressure. In other words, the attacker is not exploiting human psychology inside the model. The attacker is exploiting learned behavioral patterns that produce human-like responses. The core issue is therefore not that existing OWASP categories are incorrect. The issue is that application-security terminology alone cannot fully represent the security properties of probabilistic and context-sensitive systems. In traditional software security, the main question is often: Can the attacker bypass a technical control? In AI security, additional questions are necessary: Can the attacker alter the system’s understanding of the task? Can the attacker redirect its objective without directly violating a technical rule? Can the attacker influence its memory, reasoning process, trust model, or use of tools? Can a sequence of harmless-looking interactions produce a harmful system-level outcome? AI security therefore requires more than an expanded version of application security. It requires a multi-layer threat model that covers technical controls, data integrity, semantic manipulation, behavioral influence, memory, autonomous action, human interaction, and broader systemic consequences. 💻@ThreatSignal

بنظرتون یه کانال یوتیوب داشته باشیم رفقا؟

⚡️

▶️امشب ساعت 9:30 ایونت داریم و از بچهایی که موفق شدن چالش رو پشت سر بزارن ازشون سوال میپرسیم

🍊Gu Poison ⬅️بعضی از بچها چطوری تو چالش موفق شدن؟! با این روش 💻@ThreatSignal