Agregátor RSS

“Hallucination” has become the catch-all term for AI getting things wrong. It describes a real phenomenon: Large language models can generate confident, fluent answers that are simply untrue.

But in IT operations, many errors labeled as hallucinations have a more ordinary explanation. The AI isn’t inventing facts. It’s faithfully reporting information that happens to be outdated, incomplete, or contradictory. I’ve seen this play out across enough environments to know the cause usually sits upstream, in the data the system learned from and the picture of the estate it read.

Fix the data foundation under your AI systems →

That distinction matters, because the fixes are different. You don’t tune the model. You fix the information it relies on.

When the answer is wrong, but the logic is right

Imagine a service desk analyst asking an AI assistant whether a user’s laptop has received the latest security update. The assistant says yes. The analyst closes the ticket. Two days later, the device is flagged in a vulnerability scan. What happened? The assistant pulled from an endpoint record last updated before the device went offline for a week. The data was accurate when it was written. It wasn’t accurate when it was used.

Or consider a knowledge article describing a VPN troubleshooting procedure that was retired after a network change. An AI assistant retrieves it, summarizes it neatly, and recommends steps that no longer apply. The model performed well. The source didn’t. In each case, a human reviewer reading the same record would likely have made the same mistake.

This is not a rare edge case. In a 2026 survey of 3,900 employees across six countries, including 1,500 IT professionals, 68% of IT pros reported personally seeing AI produce hallucinations with potential operational impact. Just over half caught the errors before they caused problems, while 16% did not. That’s a significant chunk of wrong answers making it into real workflows, and those are just the ones people noticed.

3 data problems behind unreliable AI

Firstly, most trust issues with AI in IT operations trace back to a few recurring patterns. Poor data quality (missing fields, inconsistent naming, duplicate records) makes it hard for any system to produce accurate answers.

Stale information is the second pattern. IT environments change constantly. Devices move, users change roles, software is updated. Data that was correct last month may be misleading today, especially when AI presents it with no indication of age. Autonomous endpoint management can help keep records current, but many organizations still rely on periodic manual cleanups that leave gaps.

The third is conflicting records. When two systems disagree, AI may pick one arbitrarily, blend them, or produce an answer that matches neither. Without a clear rule for which source wins, the output becomes unpredictable.

Explainability and governance build trust

For IT teams, a useful AI answer isn’t just correct. It’s checkable. When an assistant recommends an action, practitioners need to see where the recommendation came from. Which record did it use? When was it last updated? Did other sources disagree? Explainability turns AI from a black box into a colleague whose reasoning can be reviewed. It also speeds up correction: If an analyst can see that an answer came from a stale knowledge article, they can flag the article instead of losing faith in the entire tool.

The governance measures that reduce unreliable output are less about tuning models and more about maintaining the information they rely on, as the Ivanti Neurons platform is designed to do. Set freshness thresholds so data older than a defined window is flagged or excluded. Establish source-of-truth rules for when systems conflict. Assign owners to knowledge content with scheduled review dates. Log AI recommendations and outcomes so recurring errors can be traced to their source. And give practitioners an easy way to report incorrect answers.

Trust is earned in small moments

Adoption of AI in IT operations rarely fails in one dramatic incident. It erodes gradually, one questionable answer at a time, until practitioners quietly stop using the tool. The reverse is also true. Trust builds when answers are consistently accurate, sources are visible, and errors are easy to trace and fix.

Reliable AI starts with reliable information. The instinct when a system produces a confident wrong answer is to blame the model. Most of the time, the technology did exactly what it was told. It just wasn’t told the truth.

Make your data trustworthy before you trust your AI with it →

Díky smartphonům můžeme dnes fotit kdykoliv a kdekoliv • Při focení však děláme spoustu chyb • Toto jsou ty nejčastější, které dělají snad úplně všichni

The popular LiteLLM Python package has been compromised as part of a software supply chain attack that delivered a credential stealer and a backdoor, according to reports from SafeDep, Socket, StepSecurity, and Upwind. The compromise affects LiteLLM 1.107.0, distributed through PyPI wheels and Docker images. The Python package has since been quarantined on Python Package Index (PyPI), and the Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

Ask an IT team a simple question, “How many laptops do we have?” and the answer often depends on who you ask and which console they open.

For years, that ambiguity was manageable. People reconciled the differences in their heads, in spreadsheets, or in meetings. Ivanti research shows that 34% of organizations still track IT assets in spreadsheets, which shows how much reconciliation still happens by hand.

Build the authoritative data source your AI can act on →

Automation changes the stakes. When software acts on data without a person double-checking it first, the question of which data is correct stops being academic. People tolerate ambiguity and ask questions. Automation doesn’t. It executes at scale and at speed.

What a system of record actually means

A system of record is the authoritative source for a specific type of information. It is the place everyone agrees to trust when systems disagree. That doesn’t necessarily mean a single database holding everything. In most environments, it is more realistic to establish clear authority by data domain. One source might be authoritative for device identity and hardware details, another for user and identity data, another for service relationships and dependencies. What matters is that the authority is explicit, documented, and respected by every process and tool that consumes the data, including automation.

Consider what happens without it. An automated workflow deploys a patch to a device, but the device record is duplicated and the patch targets the wrong machine. A rule flags laptops that haven’t checked in for 60 days as possibly lost, but the check-in dates are stale, so active devices get flagged anyway. If HR and IT systems disagree about an employee’s status, access may be revoked too early or not at all. Each rule is only as good as the data behind it.

Ownership, authority, and traceability

Data ownership and data authority are two concepts that often get blurred. Ownership is about accountability: who is responsible for keeping a data domain accurate, resolving conflicts, and approving changes. Authority is about precedence. When two systems hold different values for the same attribute, which one wins? Both need to be defined. A source can be technically authoritative, but if nobody owns its accuracy, quality will drift.

A practical way to start is to list the 10 to 15 attributes automation relies on most: device name, owner, location, operating system, criticality, last check-in, and assign both an authoritative source and an accountable owner to each.

Traceability matters just as much. When an automated action goes wrong, the first question is always, “Why did it do that?” A trusted system of record makes that question answerable. If teams can trace an action back to the specific record and attribute that triggered it, along with when that data was last updated, troubleshooting takes minutes instead of days. Without it, teams are left reconstructing events from scattered logs and memory.

Context and foundation

Raw records aren’t enough. Automation also needs operational context: which business services a device supports, how critical it is, who depends on it, and what maintenance constraints apply. A server running payroll at month-end should not be treated the same as a test server, even if both share the same vulnerability. Context allows automation to make proportionate decisions instead of uniform ones, and the Ivanti Neurons platform is built to connect asset data with service maps, ownership, and business priorities.

It is tempting to start an automation program with the workflows themselves. They are visible, measurable, and satisfying to build. The data foundation underneath is harder to show off. But teams that skip it tend to automate their inconsistencies and then spend months chasing the side effects. Autonomous endpoint management requires a foundation you can trust, and that investment pays off in every workflow built on top of it.

The organizations getting real value from AI didn’t start with the model. They started with the data. Because without trusted data, AI is just guessing. And in enterprise IT, guessing isn’t a strategy.

Anchor your automation in data you can trust with Ivanti →

Make sure you don’t say anything mean or secret after hanging up a call on Signal, as a bug in the encrypted messaging app’s calling library could prevent a call from ending properly, potentially leaving audio and possibly video active. The vulnerability, CVE-2026-113380, was published by MITRE on Tuesday and given a CVSS score of 9.3, marking it as a critical issue in Signal’s open-source RingRTC library in every single version before 2.72.0. That update was pushed out last month, but the vulnerability wasn’t made public until now. RingRTC is Signal’s own calling library built on top of WebRTC, a technology introduced in 2011 that has since become widely used for voice and video communication over the internet. RingRTC provides Signal-specific calling functionality using WebRTC, which already encrypts media traffic, but that isn't stopping RingRTC from failing to hang up calls in certain conditions, according to the CVE report. What’s happening is, in essence, a denial-of-service attack on RingRTC’s finite state machine (FSM) event queue, which handles events involved in managing calls. If one of the people on the call saturates the FSM queue with requests, it can become overwhelmed and fail to process a hangup request, preventing the call from terminating properly. The vulnerability is classified as CWE-754, or improper checking for unusual or exceptional conditions, according to a report posted to GitHub. A conceptual proof of concept is available in the GitHub report linked above, using a Python script to simulate how flooding an event queue can prevent a hangup request from being processed. Were a malicious actor to exploit this, the person on the other end may think the call has been terminated, but either or both of their video and audio channels could still be open. The attack complexity is considered low according to the CVE, and while CISA’s known exploited vulnerabilities catalog doesn’t indicate this has been spotted in the wild, Signal users ought to ensure they’ve updated their apps - mobile and desktop - to the latest versions to ensure they don’t end up being caught on a hot mic without any notice. Comparing RingRTC 2.72.0 to the previous version indicates that Signal's fix allows the call's finite state machine (FSM) to detect termination requests independently of the event queue, while adding a timeout to prevent stalled processing from indefinitely blocking a hangup. It's not entirely clear from Signal's release notes when the fixed version of RingRTC reached the Android, iOS, and desktop versions of its apps. Signal Desktop's release history indicates that RingRTC 2.72.0 was incorporated in September, but the precise rollout dates across all platforms remain unclear. We’ve reached out to Signal to learn more, but haven’t heard back. In the meantime, best to update your installation to be sure you’re not still vulnerable. That, and watch what you say after hanging up a call. ®

Roborock přináší na český trh praktickou novinku – robotický vysavač Saros 20 s dokovací stanicí určenou k pevnému připojení k přívodu čisté vody a odpadu. Pokud máte běžnou dokovací stanici, mobilní aplikace jednou za čas nahlásí, že došla čistá voda, takže musíte vzít zásobník do ruky a dojít ke ...

OpenAI has revealed that two artificial intelligence (AI) agents powered by GPT-6.1 Sol and GPT-6 Astra weakened misalignment monitoring while making requested software changes during two internal coding tasks. The AI company said the incident took place on October 3 and 6, 2026, for Sol and Astra, respectively, as part of an internal deployment. "A GPT-6.1 Sol agent repairing an evaluation Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

OpenAI agents powered by the GPT-6.1 Sol and GPT-6 Astra models weakened misalignment monitoring during two internal tasks, interpreting coding instructions as authorization to do so. [...]

Trh ohebných telefonů rychle roste a brzy mu pomůže i Apple • Samsung chce v roce 2027 představit šest ohebných novinek • Rolovací model Galaxy Z Slide má odstranit ohyb, ale prověří odolnost konstrukce

Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.

UPD 23.10.2026: added Kaspersky SIEM rules and events for developing custom detection rules or conducting threat hunting.

UPD 22.10.2026: added a description of how the Kaspersky Managed Detection and Response service detects the described malicious activity.

UPD 22.10.2026: added a description of how Kaspersky Vulnerability Management detects vulnerable versions of PHP.

Vulnerability overview

On October 20, 2026, the PHP security team published a preliminary notice regarding an upcoming emergency release that addresses two critical vulnerabilities (both rated 9.2 on the CVSS scale). The patches were released on Wednesday, October 21, 2026, at 14:00 UTC.

The release was expedited after information about the vulnerabilities was leaked to the public before the scheduled embargo was lifted. In a post on Hacker News, a user reported two RCE vulnerabilities in PHP, allegedly affecting all versions starting with PHP 5.4.0.

The vulnerabilities in question are CVE-2026-109618 and CVE-2026-109619. Shortly after the post appeared, researchers confirmed the existence of the vulnerabilities. Along with the leak of details, an exploit unofficially named PHP2Shell appeared online. In the leaked demo video, the exploit is shown in action on web servers running WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS — platforms that power many modern websites. The authenticity of the demonstration and the exact behavior of the exploit had not been independently verified at the time of publication.

According to the researcher who published the PoC, the vulnerabilities are related to the handling of the multipart/form-data MIME type in conjunction with the session upload progress mechanism (session.upload_progress) in the PHP core and fall under the categories of use-after-free and memory corruption. This means that the flaws cannot be fixed via application code, and the only fix is to update PHP on the server. The attack requires no authentication: an attacker with network access to a PHP application can execute arbitrary code with the privileges of the PHP process without needing to authenticate. Security advisories issued by the PHP team on October 21 confirm this information.

The vulnerabilities affect PHP versions 5, 7, and 8. As of this publication, branches 8.2 through 8.5 are supported. Older branches, including PHP 8.1, 8.0, 7.x, and 5.x, have reached the end of their lifecycle; however, due to the critical severity of the vulnerabilities, backported patches have also been released for versions 7.4, 8.0, and 8.1.

Sansec experts estimate that widespread exploitation could begin within 15 minutes of the update’s release. We strongly recommend that administrators responsible for publicly accessible PHP web servers take the following steps before the patch is available:

1. Take an inventory of all PHP-based systems in your infrastructure (such as web servers, control panels, and third-party software).
2. Disable upload-progress: set session.upload_progress.enabled = Off using the php_admin_flag in PHP-FPM pools.
3. Block multipart requests on nginx and Apache servers.
4. Consider temporarily isolating PHP applications that connect to the Internet until fixes are released.
5. Be ready to install the patch immediately upon its release.
6. Plan to migrate servers running unsupported versions (8.1 and earlier) to the latest PHP branch.

Detection by Kaspersky solutions

Kaspersky solutions detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.

When an attempt is made to exploit these RCE vulnerabilities, Kaspersky Endpoint Detection and Response promptly alerts the user to suspicious actions performed in the context of a web server, on both Linux and Windows machines. This activity is detected by the following rules:

• creating_windows_shell_from_a_web_servers_process;
• possible_web_shell_creating_via_exploit;
• spawning_process_from_webserver_more_filters_linux;
• webserver_interpreter_execution_linux;
• executable_file_in_www_folder.

Detection of the PHP2Shell vulnerability exploit by KEDR

Exploitation of the PHP2Shell vulnerability in network traffic is detected by Kaspersky Anti Targeted Attack (KATA). This solution detects such activity with the following verdicts: Exploit.CVE-2026-109618.HTTP.C&C and Exploit.CVE-2026-109619.HTTP.C&C.

Detection of the PHP2Shell vulnerability exploit by KATA

Kaspersky Endpoint Security, now available as Kaspersky Next, also detects malicious post-exploitation activity using the Behavior Detection component, with verdicts such as PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

Our Kaspersky Vulnerability Management solution detects vulnerable software versions using the Vulnerability scanning and Agentless black-box scanning components.

Detection of the PHP vulnerability in Kaspersky Vulnerability Management

The Kaspersky Managed Detection and Response service detects the exploitation of the described vulnerabilities by monitoring activity characteristic of RCE:

• Spawning of suspicious processes by the web server;
• Creation of suspicious executable files in the web application directory;
• Creation of suspicious scripts in the web application directory;
• Creation of files with uncommon extensions in the web application directory;
• Execution of reconnaissance commands by the web server process;
• Execution of persistence commands by the web server process;
• Delivery and launch of web shells on the web server.

Moreover, MDR detects other malicious activity not directly related to remote code execution.

To protect companies that use our Kaspersky SIEM system, the product repository includes rules that help detect the following malicious activity.

• Execution of suspicious executable files by web server processes on Windows and Linux machines:
  • R300_04_Windows shell started by a web application
  • R152_08_A running Linux shell process has a suspicious parent process
• Execution of reconnaissance commands by the web server process:
  • R286_05_Possible web-shell (Linux)

We also recommend monitoring the creation of scripts or executable files in the web server directory when developing your own detection rules or conducting threat hunting:

((DeviceEventClassID = '4663' AND DeviceCustomString1 ilike 'WriteData') OR DeviceEventClassID = '11') AND match(FileName,'(?i).*\.(php|asp|aspx|ashx|jsp|js|jar|jse|dll|exe|bat|ps1|vbs|wsf|wsh|msi|msp|hta|cpl)$') AND match(DestinationProcessName,'(?i).*(php-cgi|nginx|httpd|w3wp)\.exe')

Name = 'openat' AND has(SA.Nametype, 'CREATE') AND length(arrayFilter(x -> match(x, '(public_html|var/www|usr/local/apache2|usr/local/httpd|var/apache|srv/www|home/httpd/html|srv/http|usr/share/nginx/html|var/lib/pgsql/data|usr/local/mysql/data|var/lib/mysql|var/vsftpd|etc/bind|var/named)'), SA.FileName))>1 AND length(arrayFilter(x -> match(x, '\.(aspx|asp|asmx|asax|ashx|jspx|jsp|js|phpt|php|phtml|pht|cfm|shtml|htaccess|fcgi|cgi|pl|py|sh)'), SA.FileName))>1

TCL u vyšší řady C8L nesází jen na další přihazování jasu. Základem výborný, kontrastní HVA panel, jemnější řízení podsvícení a konečně také čtyři plnohodnotné vstupy HDMI 2.1. Výsledkem je jeden z nejlepší letošních televizorů, který uspokojí filmové fanoušky, náročné hráče, ale také naprosto ...

PHP developers have released emergency updates for two critical vulnerabilities after cybersecurity authorities warned organizations to patch immediately or consider taking exposed applications offline. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 address CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution. The project's developers urged users to update immediately. All PHP installations serving web requests are potentially affected, including deployments using PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, and LiteSpeed, the developers said. "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Jake Knott, head of threat intelligence at watchTowr, said: "As expected, watchTowr Intel is already observing in-the-wild exploitation of the latest PHP vulnerabilities, with a variety of vibecoded PoCs already hitting our sensors featuring a variety of 'php2shell' User-Agents. Whilst nobody has been successful to date, we don't expect that will last long." "Where immediate patching is not feasible, organizations should consider isolating internet-facing applications from public networks until a fix is available," CERT-EU said in an advisory issued ahead of the patches. The body lists both vulnerabilities with CVSS scores of 9.2. Finnish government services and websites belonging to the Dutch parliament, cybersecurity authorities, and data protection regulator were taken offline as a precaution. Privacy campaign group noyb also temporarily withdrew its website. PHP "powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn't even advertise that it runs PHP under the hood," infosec vendor Huntress noted. That makes identifying exposed installations a substantial job. "The number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast," said John Hammond, Huntress's senior principal security researcher. ®

Spojené státy zakázaly prodej síťových zařízení vyráběných jinde než doma. Dočasně však udělují výjimky a ty již získali všechny velké nečínské společnosti. Situace je nejvýbušnější u čínského TP-Linku. Jde o největšího výrobce routerů pro domácnosti. Americká vláda tuto společnost dlouhodobě ...

Americký Letecký úřad certifikoval dopravní letoun Boeing 737 MAX 10 • Výrobce musel přepracovat klíčové bezpečnostní i navigační systémy • Letecké společnosti očekávají zahájení dodávek na počátku roku 2027

The PHP security team released emergency security patches for two critical remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619) tracked collectively as PHP2Shell. [...]

Private keys associated with eight intermediate certificate authorities operated by Indian digital trust provider eMudhra have been compromised, potentially allowing attackers to forge trusted certificates and impersonate websites or services, according to Google and Mozilla.

“On 17th October @ 20:06 UTC, Mozilla received a report to [email protected], forwarded by the Chrome Root program, that the private key of 8 eMudhra Intermediate certificates have been compromised,” Dennis Jackson, a member of Mozilla’s engineering team, wrote in a public Mozilla bug report. “An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.”

Mozilla independently recovered the keys later that day, confirming that they were vulnerable.

“Mozilla was able to recover the private keys for the impacted certificates independently @ 21:48 UTC and without any knowledge of the method the original reporter used,” Jackson added in the report. He said the recovery confirmed that “the key generation process was flawed and is trivial to exploit.”

The report was submitted by a researcher identified as Wayne and forwarded by the Chrome Root Program. Mozilla acknowledged it and subsequently began blocking the affected certificates in Firefox.

eMudhra acknowledged the report and said it was investigating, according to the Mozilla report.

“One of eMudhra’s certificate authority private keys is the number 4,” security researcher Scott Helme wrote in a separate analysis. Two other keys had values of 56 and 115, he said. Helme recovered all eight from their public certificates in less than a second.

Six of the eight affected intermediate certificates were intended for Transport Layer Security (TLS), which browsers and applications use to authenticate websites and establish encrypted connections, according to Google’s security blog post. The other two were for code signing.

“The private keys for these certificates were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs,” Google added in the blog post.

Browser blocks and enterprise exposure

Google’s Chrome Root Program received a report and deployed a Chrome Revocation List Set update blocking the affected intermediate authorities, according to the company’s security blog.

“Chrome users were immediately protected against all certificates sharing those keys, without requiring a browser update or restart,” Google added in the blog post. Android devices and Chromebooks also received an equivalent update through Google Play Services.

Google said no TLS certificates chaining to the six affected intermediates appeared in Certificate Transparency logs before the blocking action. It said no fraudulent certificates issued by those authorities could have been used against clients enforcing Certificate Transparency, including Chrome’s default configuration.

Mozilla said in its security blog post that it completed the distribution of its OneCRL block to Firefox users with standard configurations. Mozilla also announced updates for users whose custom settings might have prevented them from receiving the block.

Google said it had removed the emSign ECC Root CA – G3 certificate, which signed the affected intermediates, from the Chrome Root Store. The change was scheduled to reach all devices relying on that store on October 27.

Enterprise applications face separate checks

Yash Kadakia, founder and CTO of Security Brigade, estimated that about 30,000 legitimate certificates would need to be migrated. He said government and public-sector websites using the affected hierarchy could face browser warnings or access disruptions if replacement certificates were not installed in time.

“This isn’t just about eight compromised keys. It’s about the global internet’s chain of trust,” Kadakia said. “A single authority’s failure can undermine authentication for organisations that have never dealt with it.”

Kadakia said enterprise security teams should check payment gateways, vendor integrations, older Java applications, mobile apps, and network appliances, which may use certificate trust stores separate from browsers.

“Security teams need to identify both the certificates their services present and the certificate authorities their applications trust,” he said. He advised organizations to test whether affected clients reject certificates signed by the compromised keys, including cross-signed chains.

Cloudflare said in its October 20 incident report that it learned of the compromise on October 19 and deployed mitigations across its content delivery network, developer services, and Zero Trust products. It also updated shared trust stores and base images and released updates for Cloudflare One clients and Cloudflare Tunnel.

“Our security review has not identified active exploitation of this issue on Cloudflare services,” the company said in its report.

eMudhra says no end-entity certificates were issued

eMudhra, in its incident statement, said the affected intermediate authorities were created during a key-generation ceremony in April 2025. It said the incident did not affect its root CA private keys or other intermediate authorities.

“None of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates,” the company said. It said its internal analysis was corroborated by public Certificate Transparency records and that it was investigating the incident and reviewing its security controls.

Kadakia said the absence of issued end-entity certificates was reassuring, but noted that someone holding a compromised intermediate key could generate fraudulent certificates without requesting them from eMudhra.

eMudhra did not immediately respond to a request for comment.

This article originally appeared on CSOonline.

ClickFix attacks are surging as cybercriminals use fake AI installers, malicious search results, and trusted chatbot platforms to trick users into executing malware. Push Security examines how these attacks evade traditional defenses and why AI tools have become increasingly effective lures. [...]

PHP has released emergency updates that fix two critical flaws in the language itself, letting an attacker without an account run code on a web server. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP team says only updating fully protects a server. The flaws, together called PHP2Shell, sit in the PHP runtime, not in any application, so a site is exposed even when its own Swati Khandelwalhttp://www.blogger.com/profile/[email protected]