Agregátor RSS
U.S. Seizes NightmareStresser Domains Linked to Hundreds of Thousands of DDoS Attacks
How Linux File Permissions Become a Root Trust Boundary
Salesforce’s massive outage exposes the hidden risks of cloud dependencies
While its flagship Dreamforce event was in full swing on Wednesday, Salesforce was triaging a roughly seven and a half hour-long service outage that disrupted user access and caused “severe delays” and intermittent errors. Some customers were also unable to submit new support cases.
The service outage hit at 3:50 a.m. EDT, impacting “multiple instances across all regions,” Salesforce reported. It was marked resolved right around 3 p.m. EDT, after several hours of monitoring to determine that fixes had been successful.
Salesforce initially pegged the issue to an “external dependency failure” impacting the legacy login server. A core system component experienced increased load, limiting its capacity to process requests. The company confirmed that there were no issues with third-party infrastructure.
Beyond the obvious embarrassment from the outage occurring during Dreamforce, an analyst said the incident highlights a cloud resilience problem, rather than purely a legacy one.
“Cloud does not eliminate architectural dependencies,” said Abbas Jaffery, a principal advisory director at Info-Tech Research Group. “It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”
Rolling restarts, persistent issues throughout the daySalesforce began experiencing service issues at 3:50 a.m. EDT on September 16, and initial investigation determined that requests were stalling while waiting on responses from an internal login service that was using up available server resources.
Initially, Salesforce blocked application programming interface (API) endpoints and attempted rolling restarts to revive the service, then pushed out fixes region-by-region. At 7:20 a.m., some customers were seeing service return to normal, and Salesforce was working on a “code-level permanent fix.”
However, the rollout did not complete for a number of instances, and some automated fixes didn’t fully resolve the issue. For example, customers reported that scheduled jobs were not running as expected, even after service was restored. Salesforce manually restarted those instances.
Salesforce later reported that the impact radius was “narrower than initially understood” and saw signs of recovery by around 11 a.m. EDT, with most customers coming back online.
A sub-set of Hyperforce instances were the last to be restored. Mitigations were in place across all instances by 11:39 a.m. EDT, and Salesforce continued to monitor the issue until marking the incident resolved at 2:59 p.m. EDT.
“We apologize for how this incident affected you and your business,” Salesforce posted on its incident blog. “We will undertake a full investigation of the incident, establishing the technical trigger, the underlying cause, and preventive action to avoid a repeat in the future.”
Creating a ‘temporal’ data problem
For customers for whom Salesforce is a system of record, several hours of authentication and service disruption can create a “temporal data problem,” Info-Tech’s Jaffery explained. “Events that should have happened at different points in time may occur later, fail altogether, or arrive out of sequence,” he said.
For instance, a customer interaction may occur through another channel while Salesforce is unavailable, but an integration, workflow, or scheduled process that normally records or propagates that event is unable to run.
This has several potential consequences, Jaffery said. Transactions and customer service processes are delayed; APIs and middleware may accumulate retries, timeouts, and queues. Records can become temporarily inconsistent, and scheduled jobs and workflows may be missed. Employees could lose visibility into customer history or case status, even when the underlying data has not been lost, creating a “data divergence.”
The first mistake would be to assume that just because users can log in, the incident is over, he noted. “Enterprises should move immediately into a reconciliation and integrity phase,” Jaffery advised. This means not only verifying interactive access, but APIs, integrations, scheduled jobs, queues, workflows, automation, authentication flows, and downstream systems.
Enterprises should ask what transactions failed, partially completed, or were duplicated during the outage? Which scheduled or asynchronous processes did not execute? Did integrations retry successfully, or did they create a backlog or retry storm? Are downstream systems now consistent with Salesforce?
Security teams should also validate authentication and session behavior, privileged access, integration credentials, and any emergency changes made during recovery, Jaffery explained. “The most important question is not simply ‘Is Salesforce back?’, but ‘What did the business expect to happen during the outage, and can we prove that it actually happened?,’” he said.
What to look for in post-incident reportsA credible post-incident review from Salesforce should establish a causal chain: The trigger, dependency failure, technical propagation, customer impact, detection, mitigation, recovery, and permanent corrective action, Jaffery said.
The company should be able to answer these questions, he said:
- What was the actual initiating failure and why did the failure propagate into the login path?
- Why could the affected dependency consume sufficient capacity to affect core services?
- Why didn’t isolation or failover prevent the impact?
- Why did initial remediation attempts fail and why did the subsequent rollout require additional intervention?
- What safeguards are being added to prevent recurrence?
- How will Salesforce demonstrate that the corrective action actually works under failure conditions?
Service restoration simply tells customers: “We got it working again,” he noted. But root cause analysis tells customers: “We understand why it failed, why our controls didn’t prevent it, and what has changed so that the same failure mode is less likely to recur.”
It’s not just about ‘legacy’ pieces in the stackOne architectural lesson is that a legacy component does not have to be large to be critical, Jaffery pointed out. An older authentication service can remain part of a modern stack, and therefore become a dependency for newer services.
“The component’s age matters less than its position in the dependency graph, its blast radius, and the quality of its isolation and failure handling,” he said, pointing to this incident’s progression: Requests stalled waiting on an internal login service due to increased resource consumption led to investigation into an external dependency failure, which in turn revealed impact on a legacy login server. Finally, Salesforce said, “core system components experienced increased load, which limited its capacity to process request”.
That is a classic resilience question, Jaffery pointed out: Can a failure in one dependency remain in that one dependency, or does it become a platform-wide failure?
Modernization should not be identified simply by how much old technology has been replaced, he noted, it should also measure dependency concentration, isolation, “graceful degradation,” recovery paths, and failure blast radius.
“For enterprise architects, that is the real takeaway,” he said.
Maybe driven by agentic AI, exacerbated by layoffsAt this point, there are no obvious signs that this was a security incident, noted David Shipley, CEO of Beauceron Security. “Right now, this bears all the hallmarks of an update gone horribly wrong.”
He pointed to an incident in December 2025 when Amazon’s internal AI coding agent, Kiro, caused a 13-hour AWS outage in a mainland China region, noting, “I’m not going to be shocked if we don’t see some kind of agent role in this kind of scale disaster.”
Significant Salesforce layoffs over the last few years could also have had a negative impact on the outage and recovery, he added. “Having it happen during Dreamforce had to be all kinds of hell, though, for their sales and customer support teams,” he said. “Pour one out for them as they work on rebuilding relationships, face-to-face.”
This article originally appeared on CIO.com.
Anthropic wants Claude to analyze your bank account and financial data
Docker Sandboxes Flaw Lets a Guest Reach Host Unix Sockets
Acronis Backup Flaw Is Being Exploited on Linux Hosting Servers
AI agents can modify themselves without humans telling them to do so
Dny Marianne 2026 startují. S kupony ušetříte, s Mastercard získáte slevu navíc
Chtěla ušetřit 245 tisíc za provizi. Nejvyšší soud ale řekl, že realitka má na peníze nárok
AI po expozici: když editor začne měnit realitu
Jak rychlý je vlastně jazyk Action! na osmibitových Atari?
Jen-Hsun Huang: Čína bude mít vlastní litografické nástroje do 4 let
Myši s „lidským“ xenokortexem jsou průlomem v organoidech
Fedora Linux 45 Beta
Nonprofit that tracks meteors taken down by "critical blow" from a cyberattack
The International Meteor Organization, the nonprofit that coordinates and publishes amateur and professional observations of meteor phenomena, said its infrastructure has suffered a “critical blow” from a cyberattack.
“We recently suffered a cyberattack that dealt a critical blow to aging infrastructure, taking much of our site offline," a static page on its website on Wednesday said. “We expect several weeks of partial downtime as we transition to new infrastructure and services.”
“I am very sad to see the site down”In the meantime, the IMO said it’s prioritizing the reporting of fireball observations, which can be reported here. The organization is also providing some information on its Facebook page.
Windows 11 KB5124008 update breaks domain trust for some users
CISA decides weekly vulnerability bulletin isn't necessary anymore
Iranian hackers use CHOSEN BRICK Windows malware to spy on targets
LinkedIn fights for the right to tell customers when the feds want their data
Microsoft’s top lawyer argued Tuesday that legislators “must make secrecy [orders] the exception” in government subpoenas demanding information about LinkedIn users.
LinkedIn, which is owned by Microsoft, is fighting what it calls overly broad subpoena demands from the US government, which sometimes come with secrecy orders that prevent LinkedIn from alerting customers whose information is being requested.
The company is asking federal courts “to enforce meaningful limits on both the scope of government demands and the secrecy that can accompany them,” wrote Jon Palmer, Microsoft’s chief legal officer, in a Tuesday blog post. “We recognize law enforcement’s important role in protecting public safety and investigating crime, and sometimes that does need to be done covertly. At the same time, customers and users deserve meaningful limits and independent oversight through an adversarial process.”
He pointed out: “People and organizations increasingly entrust their most sensitive information to online services. If providers cannot challenge demands they know are overbroad—or if courts may silence them without a rigorous, adversarial review—the safeguards the law requires will be weakened precisely when they are most needed.”
A tricky issueThe issue is a tricky one. Law enforcement often use this type of subpoena as an investigative tool, seeking those who are engaged in illegal activities. The theoretical justification for secrecy is to avoid alerting the investigative target to make it less likely the suspect will try to destroy evidence or flee the jurisdiction.
Government lawyers are supposed to only make secrecy requests when absolutely essential. Microsoft is suggesting that courts and congress need to step in to curtail blanket government efforts.
“The Fourth Amendment protects the right to be free from unreasonable searches and seizures. That right applies to papers kept in a desk and it also applies when personal and business records are stored online,” Palmer wrote. “Online service providers, like LinkedIn and Microsoft, also have a First Amendment right to speak to their customers when the government obtains an order to search their private information. Secrecy may sometimes be justified, but it should be tailored to demonstrated needs and subject to meaningful review.”
He added: “The government must seek only relevant information, justify secrecy with specific evidence and infringe on speech to the least extent possible.” In his post, he pointed to a recent legislative effort in the US House of Representatives that might mitigate the issue if it ends up becoming law.
“On August 31, the House passed legislation to rein in secret surveillance and strengthen notice protections when the government seeks data held by technology providers,” he wrote. “The reforms would place clearer limits on secrecy orders, require greater accountability, and help ensure that secrecy is the exception – not the rule. The Senate should act promptly to send these historic reforms to the President.”
LinkedIn privacy battlesLinkedIn itself is currently fighting litigation that accuses it of directly violating the privacy rights of its customers, and a federal judge this month dismissed another similar case, but gave plaintiffs permission to refile, with a caveat.
“Given LinkedIn’s further arguments that users voluntarily download browser extensions, which by their nature intentionally expose data to websites, it seems unlikely that the plaintiffs will ever be able to allege a privacy violation, much less prevail at the end of the day,” US District Court Judge Vince Chhabria wrote. “But in an abundance of caution, dismissal is with leave to amend.”
But, he added, if the amended complaint isn’t filed within 14 days, “dismissal will be with prejudice.”
Privacy now a ‘data stewardship obligation’Jeff Valdes, a director at Acceligence, noted, “there is definitely some irony here.”
“If Microsoft wants customers to view it as a steward of their privacy when the government comes asking for their information, customers are naturally going to apply that same standard to how Microsoft and LinkedIn collect, use, protect, and disclose information themselves,” he said. “Privacy is difficult to compartmentalize. You cannot have one philosophy of customer privacy for government access, another for product design, and another for your own commercial data practices without eventually creating a credibility problem.”
Mike Wilkes, enterprise CISO at Aikido Security, agreed, pointing out, “without meaningful limits, judicial scrutiny, and an expiration mechanism, a temporary investigative necessity starts looking a lot like a permanent architecture for invisible surveillance. The individual may never have an opportunity to challenge the scope of the request, because they may never even know the request existed until prosecutors show up with an indictment.”
That, he said, “is why Microsoft’s argument matters, despite the obvious irony of LinkedIn simultaneously defending itself against privacy claims from its own users.”
But Ryan O’Leary, an IDC research director, offered a different perspective.
“Microsoft makes no bones about using the data contained within its own systems for its own purposes. Both things can be true: Microsoft can fight for the privacy of its platform while still not necessarily respecting the privacy rights of its end users,” O’Leary noted. “This seems to come down to protecting its own proprietary data sets, not some altruistic privacy crusade.”
At the same time, Valdes pointed out, Palmer’s post highlights how deeply privacy has become a top-tier enterprise IT priority.
“Privacy is rapidly becoming a much broader data stewardship obligation,” he said. “Companies holding sensitive information increasingly have to think simultaneously about government requests, third-party access, their own collection practices, AI use, data retention and what they tell customers about all of it. If you want to be trusted as the custodian of the world’s data, customers are going to judge how you protect that data in every direction.”
However, Wilkes noted, “Microsoft does not need to be a perfect privacy saint to be right about this particular problem.”
This article originally appeared on CSOonline.
GNOME 51
- « první
- ‹ předchozí
- …
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- …
- následující ›
- poslední »



