One standard term is "shared mutable state".
Let's unpack that. "State" is any place to store data: e.g., a variable or object. "Mutable" means that the data can be modified. "Shared" means it is shared among multiple threads. Thus, shared mutable state is state that is visible to multiple threads and can be modified by multiple threads.
Usually, immutable state is not a concern: even if it can be read by multiple threads, no one can write to it, so there is no potential for data races or concurrence problems.
Usually, non-shared state is not a concurrency concern: there's only a single thread that can read or write it, so we don't have to worry about concurrency -- merely single-threaded-correctness.
Note that this also helps clarify how we should think about a case that wasn't mentioned in your original question. What about state that can only be written by a single thread, but can be viewed by multiple threads? That's shared mutable state. And that's exactly the right classification, because such state can cause concurrency problems: if you're not careful, it can cause data races and other issues, so it's only right that it be lumped together with other kinds of shared mutable state.
(For instance, in your question you write that "local variables... are not subject to modification by other threads during the execution of a method". This is true, but it doesn't go far enough. The relevant fact about local variables is that they can't be modified or read by other threads. Also, this highlights that not all local variables qualify: for instance, if you take the address of the local variable and pass that pointer to another thread, the local variable now becomes shared mutable state and is a concurrency problem.)