Search: development.we

Dinky's POST /download/uploadFromRsByLocal handler passes the caller-supplied path parameter directly to new File(path) and file.transferTo(dest) with no path validation. The route is marked @SaIgnore and /download/** is excluded from the Sa-Token interceptor, so the only guard is a header equality check against a dinkyToken value whose default (efda1551-7958-4e0f-80a8-dfd107df3e38) is hardcoded in source and shipped to every deployment. Anyone who can reach Dinky's HTTP port (8888 by default) and supplies the hardcoded token can write arbitrary files as the Dinky service account. The default Docker image runs on 8888 with no proxy or authentication and chmod 777 on /opt/dinky, so the application's own classpath, launch scripts, and static assets are writable. Demonstrated impact: overwriting /opt/dinky/config/static/index.html served attacker JavaScript to admin browsers immediately, and writing /opt/dinky/org/dinky/Dinky.class executed attacker code as the Dinky service account at the next JVM start via a classpath-shadow launched by script/bin/auto.sh. Writes are uid 9999 (flink), not root, so /etc, /root, /home, and /usr are refused. Affects Dinky v1.2.5 (the current release) and the development branch, where the code is byte-identical.

A 710 KB JavaScript payload was discovered in the compromised keyv@6.0.0 package, representing a newer variant of Shai-Hulud with enhanced obfuscation techniques. The malicious code operates with four primary objectives: harvesting credentials from local systems, CI environments, cloud platforms, Kubernetes, and Vault; exfiltrating encrypted data through dynamic HTTPS endpoints or public GitHub repositories; leveraging stolen npm credentials to publish infected patch releases across accessible packages; and exploiting GitHub credentials with GitHub Actions to compromise repositories and extract additional credentials. The campaign demonstrates sophisticated supply chain attack capabilities, targeting the npm ecosystem and development infrastructure. Multiple components were identified including obfuscated JavaScript files, VS Code configuration files, and injected GitHub Actions workflows, indicating a comprehensive approach to credential theft and lateral movement across development environments.

As organizations adopt AI, they must secure both cloud and AI environments through a unified security control plane as their attack surface expands. Because modern applications and AI workloads are built and run in the cloud, security teams must understand which exposures matter most, prioritize what can truly be exploited, and reduce risk across cloud infrastructure, applications, identities, data, and AI systems in one place. Modern IT estates now span multiple clouds and on-premises systems, with architectures built on containers, Kubernetes, serverless functions, microservices, APIs, and AI-powered workloads. This increases both the volume and the interconnectedness of security signals. The challenge is no longer identifying individual risks, but determining how misconfigurations, identities, and data exposures combine to create real attack paths, and which of these are most critical to fix at the source. KuppingerCole’s Leadership Compass: Cloud Native Application Protection Platforms (CNAPP) reflects this shift. The report describes how CNAPP is evolving from a consolidation of cloud security tools into the security foundation for AI-native enterprises, combining cloud security, AI security posture management, runtime protection, attack path analysis, cloud detection and response, and agentic AI operations into unified platforms. Read the full report Within this evolving market, KuppingerCole names Microsoft a Leader across all four of its Leadership categories: Overall, Product, Innovation, and Market. In the report’s words: “Microsoft earns its Overall Leadership with its Defender for Cloud that is redefining the CNAPP market by extending cloud security beyond infrastructure protection and into a unified security platform for cloud, data, identity, AI, and security operations, supported by one of the industry’s most advanced agentic AI ecosystems.” That recognition reflects where the category is heading: toward platforms that unify cloud and AI security into one operational view of risk. Why CNAPP is being redefined KuppingerCole makes a clear point: CNAPP is no longer about posture or visibility alone. It is becoming the operational foundation for securing AI-powered applications, services, and business processes, across the full software lifecycle from cloud infrastructure to the AI systems running on top of it. Modern environments introduce complexity across: Multicloud and hybrid infrastructure. Rapid development and continuous deployment. Containers, serverless, microservices, and APIs. AI models, agents, pipelines, and machine identities. This complexity exposes the limits of traditional, siloed tools, where cloud posture, workload protection, AI security, and the security operations center (SOC) each live in their own console. Organizations now need platforms that can: Correlate posture, runtime, identity, data, application, and AI signals. Prioritize risk based on exploitability, not severity alone. Integrate security across development, cloud operations, and the SOC. Bring AI systems into the same risk model as the rest of the cloud. Runtime intelligence is now central to this shift. Across the platforms KuppingerCole evaluated, 94% detect active exploitation of the complex attack paths they surface, moving teams from long lists of findings to the exposures threat actors can actually use. What distinguishes leading platforms KuppingerCole evaluates providers on product strength, innovation, and market presence, and, more importantly, on how effectively they help organizations manage real risk across cloud and AI. Several themes define the next generation of platforms: AI security posture management that governs models, pipelines, and AI-specific attack paths. Agentic AI that investigates, validates exposures, and helps remediate, not just detect. Runtime-driven risk prioritization focused on what is exploitable in production. Security graphs and attack path analysis across identity, data, network, workload, an…

A campaign involving 77 counterfeit extensions on the Open VSX marketplace impersonated legitimate developer tools to harvest system and development environment information. These 'evil twin' extensions transmitted metadata such as machine hostnames, workspace details, Git repository information, and continuous integration environment identifiers to a centralized server. While source code, credentials, and authentication tokens were not accessed, the collected data could enable profiling of organizations and private repositories. The malicious extensions were removed from the marketplace by August 3, 2026, but manual removal from affected systems is required.

The calculus of cybersecurity has changed. AI is reshaping how organizations build, deploy, operate, and defend digital systems. AI-powered development tools, agents, and autonomous workflows are accelerating innovation but they are also introducing new attack surfaces, new trust boundaries, and new security challenges. Microsoft has long helped organizations secure their digital estates using Zero Trust principles . That leadership was recently recognized by KuppingerCole analysts, which named Microsoft as the Overall Leader in its Zero Trust Platform Leadership Compass , ranking Microsoft highest for both product and innovation leadership. Learn more about Zero Trust for AI As organizations accelerate AI adoption, secure software development becomes more important than ever. That’s why we are expanding the Zero Trust for AI strategy with two major additions: a new AI-focused Zero Trust Assessment experience and a new DevSecOps pillar in the Zero Trust Workshop . Together, they help organizations get ready for AI by assessing exposure, risks, prioritizing remediation, and securing AI-enabled development from source code to deployment. Zero Trust Assessment tool updates: New set of assessment checks for AI, Security Operations (SecOps), and Infrastructure. Zero Trust Workshop updates: New dedicated pillar focused on Developer Security (DevSecOps) and additional guidance for AI Memory. New guidance: New practical guidance for security practitioners and a new e-book titled Zero Trust for AI, rebuilding security controls for autonomous and agentic systems . This builds directly on the Zero Trust for AI strategy announced at RSA Conference 2026 and moves the conversation from architecture to implementation. If that announcement was about establishing Zero Trust for AI, this one is about operationalizing it: giving security, engineering, and platform teams the specific controls they need to act. To learn more about our work in applying Zero Trust for AI and agents watch this Microsoft Mechanics video: New AI pillar in Zero Trust Assessment tool The Zero Trust Assessment provides an automated view of security posture by evaluating tenant configuration and activity signals across the environment and translating those findings into prioritized recommendations. As organizations adopt AI agents, Copilots, developer tools, and autonomous workflows, the Assessment helps security and platform teams establish a baseline, measure progress, and identify gaps across both traditional and AI-powered environments. It now includes expanded coverage with new pillars for AI, Security Operations, and Infrastructure (in addition to existing Identity, Devices, Network, and Data pillars), with Zero Trust for AI-focused checks that help organizations evaluate the controls required for secure AI adoption. Additionally, enhanced reporting delivers both practitioner-level guidance and executive-ready summaries that communicate risk, progress, and next steps. Results map directly into the Zero Trust Workshop’s First, Then, Next framework, transforming assessment findings into a prioritized roadmap for remediation and implementation. Together, the Assessment and Workshop help organizations move from understanding risk to executing a structured plan for continuous improvement across their Zero Trust and AI security journey. Explore the Zero Trust Assessment updates What’s New in the Zero Trust Workshop AI is fundamentally changing software development. Developers increasingly rely on AI assistants to generate code, recommend packages, create infrastructure configurations, and automate testing. While these capabilities accelerate delivery, they also amplify the consequences of governance gaps, excessive permissions, insecure dependencies, and compromised supply chains. That is why Microsoft is introducing a new DevSecOps pillar (with 15 control groups and 91 tasks that help teams apply Zero Trust from source code to cloud deployment) in the Zero Trust Workshop.…

A sophisticated malware campaign targets Roblox players by distributing fake versions of the Xeno script executor through gaming forums and Discord communities. The attack deploys a multi-stage Java infection chain that mimics legitimate Windows and gaming components, including files disguised in Xbox Game Bar directories. The final payload functions as both an information stealer and remote access trojan, capable of stealing browser cookies, Discord, Roblox, and Minecraft accounts, cryptocurrency wallets, and payment data. Beyond typical credential theft, it records keystrokes, accesses webcams, streams desktops, manipulates files, executes PowerShell commands, and provides attackers with interactive system control. Previously documented as Powercat, the malware continues active development with new command-and-control infrastructure. Activity increased significantly in March 2026, particularly threatening children and teenagers who may expose personal accounts, webcam images, and financial information fr...

Actor usage of AI is exploding. By analyzing artifacts left behind, Talos has created a detailed analysis of how we are seeing adversaries leverage the technology to include development, force multiplication, and vulnerability research. Based on the evidence Talos gathered, guardrails did not provide much protection, with most actors able to convince the models to comply despite the lack of sophisticated techniques or encoding. The pre-existing skill of the actor has a large impact on what they can accomplish with AI. Talos observed novice users able to create malicious capabilities, albeit with limited capabilities and success. Advanced users were able to build astonishing capabilities, pushing the models to create sophisticated and complex outputs. Artificial intelligence (AI) and associated language models are now ubiquitous and heavily used in both personal and professional contexts to streamline tasks and expand capabilities. With AI being used everywhere and by almost everyone, one of the biggest questions is how malicious actors are taking advantage. Fortunately, actors make mistakes and chatbots leave artifacts. Leveraging cloud-based AI models leaves behind a variety of artifacts, most notably a prompt log. These logs can take on a variety of shapes and sizes, but they are left on endpoints that are running various applications, such as Claude Code, CodeX, Cursor, or Gemini. Over the course of our research, we’ve collected a significant corpus of these files and can start discussing the ways we see bad actors leveraging these technologies. In conducting the research, three categories of activity emerged. One was using AI as a malicious software engineer, leveraging AI to write (in some cases) very sophisticated code with clear malicious intentions. Another was actors leveraging AI to scale criminal operations and campaigns. Finally, there were a lot of actors leveraging it for bug bounty or vulnerability research, rapidly accelerating their capabilities of discovery and disclosure. Each category demonstrates how threat actors are currently leveraging AI. Within each category is a wide disparity in sophistication based on the knowledge level of the actors involved. We tried to include use cases to cover the breadth of what we found. Takeaways and high-level findings With the recent disclosures from Hugging Face and OpenAI , it's clear the era of agentic attackers has effectively arrived. In that incident, the models were operating inside a sanctioned evaluation with safeguards deliberately relaxed — but they autonomously escaped their sandbox, found and chained real vulnerabilities, and compromised production infrastructure to reach their objective. The capabilities exist; the only missing ingredient is malicious intent, and it's a matter of time before threat actors supply it. For defenders, this is a wake-up call: Vulnerabilities will surface faster, exploitation will happen sooner, and the actors behind it won't need rest or downtime. As the case studies below show, the central challenge for guardrails right now is supporting legitimate dual-use work — red teaming and vulnerability research — without empowering malicious actors. One of the immediate takeaways is that guardrails are not functioning as expected. We did not encounter any sophisticated encoding or techniques designed to trick the models — most of the time it was a simple “I'm allowed to do this,” and the model complied. When guardrails did engage, they accomplished little. In one instance, we watched an actor abandon a censored model and pivot to an uncensored version, which completed the task without question. In another, a model pushed back on a distributed denial-of-service (DDoS) operator, but by that point the tooling had already been built. This wasn't specific to a single model or platform; it was across the board. The other big takeaway is that an actor's skill level largely determines how effectively AI can be leveraged and how much impact it u…

After months of dormancy, XCSSET malware version 40 emerged in April 2026 targeting macOS developers through supply chain attacks. The malware hides in Xcode projects of legitimate applications on GitHub, spreading through infected development environments. V40 features advanced detection evasion through polymorphic payload generation, fileless persistence, and in-memory execution while weakening security mechanisms. It introduces 17 distinct modules including a Chrome hijacking backdoor via Chrome DevTools Protocol and a Telegram trojanizer. The malware employs multi-layered encryption, disables system security updates, terminates cloud telemetry, and locks XProtect signature databases. Primary targeting focuses on developers across South Asia. The infrastructure utilizes approximately 40 domains registered in Russia and India, demonstrating a geographic pivot in operations.

Sooner or later, every company faces the need to upgrade its infrastructure — whether to accommodate expansion, optimize processes, or keep up with the latest trends in IT. When such a decision is made, company management typically thinks first and foremost about broad changes at the platform level — assuming that applications can simply be reinstalled and everything will work as before. And to a certain extent, that’s actually true. In an era when corporate security could be ensured solely by antivirus software on workstations, that would have worked; however, modern cyberthreats require protection at a fundamentally different level. In this post, we explore why platform migration should be discussed with the security team as well, and why simply “installing a program” isn’t enough to ensure modern-day protection. Security is no longer just a single program In the past, securing endpoints was enough to prevent most attacks. In today’s environment, endpoint protection is just one layer of cybersecurity. A modern extended detection and response (XDR) solution isn’t a single application installed on a computer; it’s a set of components that work in conjunction. They provide protection for workstations and servers, event logging and storing, infrastructure-level threat detection mechanisms, investigation tools, automated response, reporting, and asset management. Each component serves a specific purpose and places different demands on the hardware and platform. For the event storage system , disk speed is the most critical factor. In a large company, the security system generates millions of records per day, and all of them must be written quickly and then retrieved just as quickly when needed. The bottleneck here usually isn’t processor capabilities, but rather how fast the system can read and write data. Threat detection requires computing power. The system compares events in real time and determines what can be a sign of an attack, and what is normal operational activity. Response time is critical for investigation tools . When an analyst investigates an incident and pieces together what happened, they work in real time, and every second of waiting adds to the overall response time to the attack. What does this mean? When a company switches platforms, it’s not enough to simply verify that the company’s existing cybersecurity solutions support the new architecture. The answer “yes, it’s supported” is too vague. It’s essential to clearly understand exactly which parts of the cybersecurity architecture are supported — starting from which version, and what is still under development. What to ask before it’s too late To avoid unexpected complications during implementation and operation, we recommend asking the right questions in advance — during the planning phase. Here are those questions: Which specific components have been tested on the new platform? The question shouldn’t be phrased as “Is the platform supported?”; the compatibility of each part of the system should be verified. Different components of a modern information-security solution operate under different rules, which is why their compatibility is tested separately. A one-word “yes” answer should raise a red flag: a reputable vendor will always provide a detailed response — including a list of components and any caveats (where applicable). Will there be sufficient resources to handle the company’s workload? “It will run” and “it will handle needed data volume” are two fundamentally different statements. The former is verified in a lab on a test bench; the latter depends on how many events specific infrastructure generates per day, and how long the company is required to retain them under regulatory or internal policies. It makes sense to ask the vendor for recommendations on calculating resources based on specific data volumes rather than relying on general minimum resource requirements when planning. Is the security solution up to date? It’s always important to clearl…

Improper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Mitsubishi Electric MELSEC MX Controller MX-R model, MELSEC MX Controller MX-F model, Master/local module, CC-Link IE TSN interface board, Motion module, MELSEC iQ-L Series Motion Module, Motion Control Board, Block-type remote module, Block-type remote module with safety functions, Analog-Digital converter module, Digital-Analog converter module, CC-Link IE TSN compatible coupler, FPGA module, Tension meter, AC Servo MELSERVO-J5, AC Servo MELSERVO-JET, Liner Track System MTR-S series Linear track control module, Inverter FR-A800/F800/E800 Series, Industrial Robot CR800-D series controller Network Base Card, CC-Link IE TSN expansion unit, CC-Link IE TSN-CC-Link IE Field Network bridge module, CC-Link IE TSN-AnyWireASLINK bridge module, Energy Measuring Unit CC-Link IE TSN Communication Unit, GOT3000 Series, CC-Link IE TSN Communication Unit, Motion Control Software, CC-Link IE TSN Communication Software for Windows, Analysis Support Software MELSOFT VIMA, Master/Local module Designated communication LSI DeviceKit, Remote Station Communication LSI with GbE-PHY, CC-Link IE TSN Master/Local module Designated communication LSI SDK, and Remote station software development kit allows an attacker with access to a CC-Link IE TSN network to tamper with communication data (control input/output values) by sending specially crafted packets under specific timing conditions. This could allow the attacker to cause a denial-of-service (DoS) condition in the affected product by interfering with its control function or causing it to operate incorrectly.

Red Hat OpenShift Dev Spaces provides a cloud developer workspace server and a browser-based IDE built for teams and organizations. Dev Spaces runs in OpenShift and is well-suited for container-based development. The 3.29 release is based on Eclipse Che 7.119 and uses the DevWorkspace engine to provide support for workspaces based on devfile v2.1 and v2.2. Users still using the v1 standard should migrate as soon as possible. https://devfile.io/docs/2.2.0/migrating-to-devfile-v2 Dev Spaces supports OpenShift EUS releases v4.16 and higher. Users are expected to update to supported OpenShift releases in order to continue to get Dev Spaces updates. https://access.redhat.com/support/policy/updates/openshift#crw

Improper Input Validation in the decode() function of the traceparser library could allow an attacker with a corrupted kernel trace event log (.kev) file, to execute arbitrary code or cause a crash in processes that use libtraceparser in QNX hosts or targets.

A vulnerability in the Agent Development Kit (ADK) allows for continuation forgery in tool confirmations. An attacker who is able to manipulate or inject events into the session history can execute unauthorized tools by forging a tool confirmation response. This is possible because the framework did not verify if the target tool was registered to the executing agent, did not validate if the tool actually required confirmation, and did not match the confirmation arguments against the original tool call event in the history.

The U.S. Federal Communications Commission (FCC) has banned imports of new foreign-made humanoid robots and power inverters, primarily targeting Chinese manufacturers, citing national security and cybersecurity risks. The ban includes advanced humanoid robots, quadruped robots, and power inverters used in renewable energy and data centers. This move aims to secure critical U.S. supply chains and reduce dependency on foreign technology perceived as a risk. Existing devices and previously approved models are not affected. China has criticized the ban as protectionism and pledged to defend its companies. The ban may impact U.S.-China technology collaborations but is unlikely to slow China's domestic humanoid robot development significantly.

CubePilot, an Australian drone flight controller manufacturer, experienced a significant operational disruption due to a DNS hijacking attack. This attack allowed interception of network traffic, impacting their software development operations. No specific technical details or affected software versions have been disclosed. There is no information about active exploitation or available patches.

GitHub and PyPI have introduced new policies to enhance supply chain security by reducing the risk of malicious code propagation through package releases. GitHub's Dependabot now enforces a default three-day cooldown before opening pull requests for non-security version bumps, allowing time for detection of malicious versions. PyPI restricts uploading new files to releases older than 14 days to prevent poisoning of stable releases in case of compromised publishing credentials. These measures aim to reduce the risk of supply chain attacks without significantly impacting development workflows.

In the Linux kernel, the following vulnerability has been resolved: usb: free iso schedules on failed submit EHCI and FOTG210 isochronous submits build an ehci_iso_sched before linking the URB to the endpoint queue, and keep the staged schedule in urb->hcpriv until iso_stream_schedule() and the link helpers consume it. If the controller is no longer accessible, or usb_hcd_link_urb_to_ep() fails, submit jumps to done_not_linked before that handoff happens and leaks the staged schedule still attached to urb->hcpriv. Free the staged schedule from done_not_linked when submit fails before the URB is linked and clear urb->hcpriv after the free. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an EHCI host controller with a USB isochronous device to test with, no runtime testing was able to be performed.

In the Linux kernel, the following vulnerability has been resolved: xfs: fix memory leak in xfs_dqinode_metadir_create() If xfs_metadir_create() fails in xfs_dqinode_metadir_create(), the current code returns directly, leaking the allocated update and transaction state. If the subsequent commit fails, the caller-owned inode reference is left behind. Fix this memory leak by routing the create failure path through xfs_metadir_cancel(). For both create and commit failures, finish and release any inode returned to the caller, mirroring the unwind pattern in xfs_metadir_mkdir(). The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. Runtime validation used kprobe fault injection during `mount -o uquota` on a metadir XFS image. Injecting xfs_metadir_create() reproduced the old active-update path that left mount stuck later in mount setup; after this change, the same injection reported cancel_hits=1 and irele_hits=1. Injecting xfs_metadir_commit() exercised the old inode-reference leak path; after this change, it reported irele_hits=1.

In JetBrains IntelliJ IDEA before 2026.2 unauthorized file access was possible in a Remote Development session