Often, yes, this is the case.
Depending on the mechanism for account separation in use, attackers may be able to circumvent the protection provided by the host and attack other sites. The security in this area is typically poor enough that most attackers will attempt lateral movement between sites on the same server. It works often enough for them to make it part of their strategy. Here are some of the isolation tiers in use today and the protection they provide. I'll assume apache, since that's what's common. Though these same principles apply with other server software.
If no security customizations are made, the web server will run a a single user ("apache" or "nobody" or "www-data") shared between all sites, while files will be owned by specific FTP users. The intention is to restrict what sort of access the public (apache) has by making sure it doesn't have write access to your files. Unfortunately, this arrangement isn't compatible with most of today's web applications which expect users to be able to upload files, including executable code, allowing the site to self-update, install extensions, and other administrative tasks as performed through the site.
In this configuration, the code running on any one site has the same access to another site's files as that site itself would. This configuration easily leads to compromise for many web applications.
SuExec / FastCGI
With SuExec, CGI applications run under the permissions of the site owner rather than using Apache's own permissions. suPHP and suhosin both extend this behavior to PHP as well (which traditionally does not run as a CGI executable). FastCGI including fcgid also typically provide this same behavior.
Under this regime, files are typically still readable by Apache's user account, but only writable by the site owner's account. This limits most types of lateral moves, but still allows for a limited set of attacks.
One such attack I've observed happens such that the attacker creates symbolic links to the configuration files for other sites on the server, like so:
/home/user1/public_html/foo.txt -> /home/user2/public_html/wp-config.php
The user then browses that file directly, and the configuration it contains (including database passwords) gets displayed to the attacker.
A new, experimental Apache module called mod_ruid2 by Kees Monshouwer runs the apache process itself under the user's permissions. This module is now available on cPanel servers, which means it's fairly widely deployed by shared hosting environments. This protects against the attack described above, but does not protect in the face of improper permissions and management, privilege escalation vulnerabilities, and other system-level issues. It's also not compatible with a number of common features and extensions.
Custom isolation setups
It's possible to run the server under an isolation regime using chroot and similar features (such as cgroups) to offer additional isolation and security without the expense of virtualization. This option hasn't traditionally been pursued very far, though.
Without giving each user his own server, giving each user his own virtual server is the next best thing. This is the core of "cloud" hosting, and it offers relatively strong security, but at a pretty high cost.