A security flaw has been discovered in code-projects Online Shopping System 1.0. Affected by this issue is some unknown functionality of the file /checkout.php. Performing a manipulation of the argument amount_1 results in cross site scripting. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.
A vulnerability was identified in code-projects Online Shopping System 1.0. Affected by this vulnerability is an unknown functionality of the file /homeaction.php. Such manipulation of the argument cat_id leads to sql injection. It is possible to launch the attack remotely. The exploit is publicly available and might be used.
A vulnerability was determined in code-projects Online Shopping System 1.0. Affected is an unknown function of the file /action.php. This manipulation of the argument proId causes sql injection. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized.
A vulnerability was found in code-projects Online Shopping System 1.0. This impacts an unknown function of the file /login.php of the component Login. The manipulation of the argument email results in sql injection. The attack may be performed from remote. The exploit has been made public and could be used.
A flaw has been found in code-projects Online Food Order System 1.0. The impacted element is an unknown function of the file delete_food_items1.php. Executing a manipulation of the argument checkbox can lead to sql injection. The attack can be executed remotely. The exploit has been published and may be used.
A vulnerability was detected in code-projects Online Food Order System 1.0. The affected element is an unknown function of the file edit_food_items.php. Performing a manipulation of the argument dname results in cross site scripting. Remote exploitation of the attack is possible. The exploit is now public and may be used.
A vulnerability was found in SourceCodester Online Book Store System 1.0. This vulnerability affects unknown code of the file /admin/index.php?page=site_settings of the component System Settings Module. The manipulation results in cross site scripting. The attack can be executed remotely. The exploit has been made public and could be used.
A vulnerability has been found in SourceCodester Online Clothing Store 1.0. This affects an unknown part of the file /db/shopping.sql of the component SQL Database Backup. The manipulation leads to files or directories accessible. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used.
Welcome to this week’s edition of the Threat Source newsletter. “Experiment is the mother of knowledge.” ― Madeleine L'Engle, A Wrinkle in Time “Don't slide down the rabbit hole. The way down is a breeze, but climbing back's a battle.” ― Kate Morton, The Clockmaker's Daughter Hacker Summer Camp has come and gone, which means it’s time for you to start planning next year’s trip. I’m surely going to recap Camp Season, right? Nope. One of the things that I’ve really enjoyed lately is a segment on the Beers with Talos podcast that we call “Make Hazel a Hacker.” If you haven’t listened to it, this is a perfect time to start. Each episode we take a few minutes and pose a security question, term, or concept to Hazel and force her to come up with an idea or explanation on the spot. There are no parameters, so she’s faced with the entirety of information security — past, present, and future. I know, it’s insane. The craziest part is that (I think) Hazel came up with this idea and still volunteered to put herself in the line of fire. As we put Hazel’s feet to the fire, one of my favorite things happens: The rest of us listen in and offer our thoughts during her brainstorming process. Invariably, we’ve got three very different answers, ideas, hints, or directions for her. It’s surely maddening for Hazel, but to me, the best part of the discussion that inevitably follows is that although they’re all different, they’re all correct. For example, this past episode I asked her about a behavioral indicator (regarding “wallpaper.bmp”) that seems benign on its own, but can be interesting to use as a pivot for a threat hunt. We had various interesting angles to consider, backed by years of knowledge and experience. It gave us a good conversation, and that was a .bmp! One of the most nebulous things to learn in this field is that multiple things can be both different and correct. When you are making your decisions this week — whether it’s deciding on a new pivot in your hunting, what devices to prioritize in your patching and updating, or which books or online training to focus on — take a quick second and get a second, third, and fourth opinion. Then try something that’s outside of your normal wheelhouse but sounds good when it’s proposed. None of this is a solo sport. It’s a team game and the best plays come from a mix of perspectives, experiences, and mistakes. The “right” answer can wear many faces, and your ability to hold different truths will lead you to undiscovered territory, the rabbit hole where anomaly lives and breathes. So... welcome back from Vegas. Now go down a rabbit hole on a path you wouldn’t normally take because one of your friends (Joe) or your mortal enemy (Dave) told you that it would work. “She'd been to Narnia, Wonderland, Hogwarts, Dictionopolis. She had tessered, fallen through the rabbit hole, crossed the ice bridge into the unknown world beyond.” ― Anne Ursu, Breadcrumbs The one big thing Cisco Talos recently discovered "JWR," a previously undocumented, real-time phishing framework and likely variant of "The Outsider" phishing-as-a-service platform. JWR uses an open WebSocket connection that allows attackers to monitor keystrokes live and dynamically steer victims through fake checkout and login flows. Currently deployed via SMS lures impersonating regional toll and postal authorities, JWR enables operators to steal payment data, 2FA codes, identity documents, and device fingerprints. Why do I care? Because JWR is operator-driven in real time, attackers can actively bypass multi-factor authentication (MFA) by prompting victims for 2FA codes exactly when needed. The sheer volume of collected data gives threat actors a comprehensive identity profile primed for extensive follow-on fraud and network compromise. Furthermore, JWR's seamless integration with legitimate e-commerce platforms like Shopify makes these lures incredibly convincing to the untrained eye. So now what? Prioritize user education around SMS-based phish…
The FBI has issued a warning about cybercriminals targeting social media and other online accounts of adults and children to steal sexually explicit images or videos. These stolen materials are used for blackmail, sold on criminal marketplaces, or shared with other criminals to coerce victims into providing more explicit content. The FBI highlights sextortion schemes involving threats to leak private content or demands for payment. Student-athletes have also been targeted in similar schemes. The FBI advises against responding to unsolicited requests for verification codes or password resets and recommends using strong passwords and multi-factor authentication.
kkFileView is a universal file online preview project based on Spring Boot. Prior to 5.0.1, the unauthenticated POST /listFiles endpoint in server/src/main/java/cn/keking/web/controller/FileController.java passes the user-controlled path parameter from FileController#getFiles to Files.newDirectoryStream without confinement to the demo directory, allowing directory enumeration outside the intended root. This issue is fixed in version 5.0.1.
kkFileView is a universal file online preview project based on Spring Boot. Prior to 5.0.1, the unauthenticated GET /addTask endpoint in kkFileView is omitted from TrustHostFilter and TrustDirFilter in server/src/main/java/cn/keking/config/WebConfig.java, allowing FileConvertQueueTask to fetch an attacker-selected URL after FileHandlerService#getFileAttribute uses the fullfilename parameter to force an OFFICE, COMPRESS, or CAD type. This issue is fixed in version 5.0.1.
Adform, a major advertising platform, remained compromised for roughly 24 hours from late on July 26 through the evening of July 27 after being breached by unknown attackers. Few people outside the industry recognize the name, but Adform serves around 1.5 billion ad impressions every day across tens of thousands of websites. That means anyone visiting any site that runs Adform ads could have been targeted. The attackers weren’t trying to install malware. Instead, they ran a script in the victim’s browser that checked the clipboard every three seconds, and if it found a cryptocurrency wallet address had been copied, swapped it for the attackers’ own wallet address. So if someone had a site with the malicious ad open in one browser tab, and was making a crypto transaction in another tab or in a dedicated app, the funds could have ended up in the attackers’ pockets instead. Adform’s owners caught the attack and fixed the problem, but there’s no guarantee a similar incident won’t happen again — which is why every user should defend themselves against malvertising . Check out our tips at the end of this post. What we know about the attack on Adform There isn’t a lot of information out there, since the company’s official statement covers only what happened and when, without getting into the root cause of the incident. Independent research has dug up technical details about how ordinary users were targeted, but none of that explains how Adform itself was breached in the first place. What’s clear is that the attackers slipped their own code into the JavaScript that loaded on every site running Adform ads. Whenever an ad was about to display, the script would load from Adform’s server, pick the right ad, and show it — but the attackers had tacked on a set of malicious functions: monitoring the clipboard, sending data about the site where the encounter happened, and the victim’s IP address back to their own server, and swapping out Bitcoin, Ethereum, and Tron wallet addresses. All it took to make it work was having any site with Adform-served ads open in one browser tab. It didn’t matter what kind of site it was, what the ad looked like, or which advertiser it belonged to. The one thing that mattered was whether the site ran over HTTP or HTTPS. According to Adform, the attack couldn’t succeed on a site loaded over HTTPS since the connection to the attackers’ server was blocked in this case. The company hasn’t shared any information on how many users were affected, or how many sites still serve their content and ads over HTTP. Malicious ads are an everyday occurrence Unfortunately, dangerous online ads have become a systemic problem. And we’re not just talking about sketchy supplement ads or gambling promos — we mean ads that spread malware or lead to sites designed to steal payment details and other valuable data. Attackers have built out industrial-scale infrastructure to pull this off, and they use several different approaches. Hacking and compromising ad servers. Adform isn’t an isolated case: attackers have previously breached Revive ad servers , for one, and spread malware through ads on PornHub . Hijacking the ad accounts of legitimate, reputable brands . All it takes is stealing a password from someone in marketing. From there, the cybercriminals run ads posing as the company they hacked, pushing fake app updates, bogus promotions, and similar scams. In the worst cases — like the account breaches at adtech.de and adxpansion.com — attackers managed to run ads that redirected victims straight into automatic malware installs ( drive-by downloads ). Buying ads directly. That’s right — attackers simply set up their own advertiser accounts and run ads for their phishing sites and malware, just like any other business online. Since ads show up practically everywhere — on websites, in apps, and on social media — these threats can turn up in pretty much any context. And you’ll find variations of this threat on both computers and mobile de…
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.